| Methods Summary |
|---|
| public static native int | free(long ctx)Free the resources used by the Context
|
| public static native long | make(long pool, int protocol, int mode)Initialize new SSL context
|
| public static native void | setBIO(long ctx, long bio, int dir)Asssociate BIOCallback for input or output data capture.
First word in the output string will contain error
level in the form:
[ERROR] -- Critical error messages
[WARN] -- Varning messages
[INFO] -- Informational messages
[DEBUG] -- Debugging messaged
Callback can use that word to determine application logging level
by intercepting write call.
If the bio is set to 0 no error messages will be displayed.
Default is to use the stderr output stream.
|
| public static native boolean | setCACertificate(long ctx, java.lang.String file, java.lang.String path)Set File and Directory of concatenated PEM-encoded CA Certificates
for Client Auth
This directive sets the all-in-one file where you can assemble the
Certificates of Certification Authorities (CA) whose clients you deal with.
These are used for Client Authentication. Such a file is simply the
concatenation of the various PEM-encoded Certificate files, in order of
preference. This can be used alternatively and/or additionally to
path.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files there:
you also have to create symbolic links named hash-value.N. And you should
always make sure this directory contains the appropriate symbolic links.
Use the Makefile which comes with mod_ssl to accomplish this task.
|
| public static native boolean | setCARevocation(long ctx, java.lang.String file, java.lang.String path)Set File of concatenated PEM-encoded CA CRLs or
directory of PEM-encoded CA Certificates for Client Auth
This directive sets the all-in-one file where you can assemble the
Certificate Revocation Lists (CRL) of Certification Authorities (CA)
whose clients you deal with. These are used for Client Authentication.
Such a file is simply the concatenation of the various PEM-encoded CRL
files, in order of preference.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files there:
you also have to create symbolic links named hash-value.N. And you should
always make sure this directory contains the appropriate symbolic links.
Use the Makefile which comes with mod_ssl to accomplish this task.
|
| public static native boolean | setCertificate(long ctx, java.lang.String cert, java.lang.String key, java.lang.String password, int idx)Set Certificate
Point setCertificateFile at a PEM encoded certificate. If
the certificate is encrypted, then you will be prompted for a
pass phrase. Note that a kill -HUP will prompt again. A test
certificate can be generated with `make certificate' under
built time. Keep in mind that if you've both a RSA and a DSA
certificate you can configure both in parallel (to also allow
the use of DSA ciphers, etc.)
If the key is not combined with the certificate, use key param
to point at the key file. Keep in mind that if
you've both a RSA and a DSA private key you can configure
both in parallel (to also allow the use of DSA ciphers, etc.)
|
| public static native boolean | setCertificateChainFile(long ctx, java.lang.String file, boolean skipfirst)Set File of PEM-encoded Server CA Certificates
This directive sets the optional all-in-one file where you can assemble the
certificates of Certification Authorities (CA) which form the certificate
chain of the server certificate. This starts with the issuing CA certificate
of of the server certificate and can range up to the root CA certificate.
Such a file is simply the concatenation of the various PEM-encoded CA
Certificate files, usually in certificate chain order.
But be careful: Providing the certificate chain works only if you are using
a single (either RSA or DSA) based server certificate. If you are using a
coupled RSA+DSA certificate pair, this will work only if actually both
certificates use the same certificate chain. Else the browsers will be
confused in this situation.
|
| public static native boolean | setCipherSuite(long ctx, java.lang.String ciphers)Cipher Suite available for negotiation in SSL handshake.
This complex directive uses a colon-separated cipher-spec string consisting
of OpenSSL cipher specifications to configure the Cipher Suite the client
is permitted to negotiate in the SSL handshake phase. Notice that this
directive can be used both in per-server and per-directory context.
In per-server context it applies to the standard SSL handshake when a
connection is established. In per-directory context it forces a SSL
renegotation with the reconfigured Cipher Suite after the HTTP request
was read but before the HTTP response is sent.
|
| public static native void | setContextId(long ctx, java.lang.String id)Set Session context id. Usually host:port combination.
|
| public static native void | setOptions(long ctx, int options)Set OpenSSL Option.
|
| public static native void | setQuietShutdown(long ctx, boolean mode)Sets the "quiet shutdown" flag for ctx to be
mode. SSL objects created from ctx inherit the
mode valid at the time and may be 0 or 1.
Normally when a SSL connection is finished, the parties must send out
"close notify" alert messages using L
for a clean shutdown.
When setting the "quiet shutdown" flag to 1, SSL.shutdown
will set the internal flags to SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN.
(SSL_shutdown then behaves like called with
SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN.)
The session is thus considered to be shutdown, but no "close notify" alert
is sent to the peer. This behaviour violates the TLS standard.
The default is normal shutdown behaviour as described by the TLS standard.
|
| public static native void | setShutdowType(long ctx, int type)Set SSL connection shutdown type
The following levels are available for level:
SSL_SHUTDOWN_TYPE_STANDARD
SSL_SHUTDOWN_TYPE_UNCLEAN
SSL_SHUTDOWN_TYPE_ACCURATE
|
| public static native void | setVerify(long ctx, int level, int depth)Set Type of Client Certificate verification and Maximum depth of CA Certificates
in Client Certificate verification.
This directive sets the Certificate verification level for the Client
Authentication. Notice that this directive can be used both in per-server
and per-directory context. In per-server context it applies to the client
authentication process used in the standard SSL handshake when a connection
is established. In per-directory context it forces a SSL renegotation with
the reconfigured client verification level after the HTTP request was read
but before the HTTP response is sent.
The following levels are available for level:
SSL_CVERIFY_NONE - No client Certificate is required at all
SSL_CVERIFY_OPTIONAL - The client may present a valid Certificate
SSL_CVERIFY_REQUIRE - The client has to present a valid Certificate
SSL_CVERIFY_OPTIONAL_NO_CA - The client may present a valid Certificate
but it need not to be (successfully) verifiable
The depth actually is the maximum number of intermediate certificate issuers,
i.e. the number of CA certificates which are max allowed to be followed while
verifying the client certificate. A depth of 0 means that self-signed client
certificates are accepted only, the default depth of 1 means the client
certificate can be self-signed or has to be signed by a CA which is directly
known to the server (i.e. the CA's certificate is under
setCACertificatePath), etc.
|
