...
org.apache.synapse.transport.nhttp.HttpCoreNIOSSLSender
As far as the actual implementation of the transport is concerned, these two These classes are available in the synapse-nhttp-transport.jar bundle. These classes simply extend the HTTP-NIO implementation by adding SSL support to it. Therefore, they support all the configuration parameters supported by the HTTP-NIO receiver and sender . In addition to that, both HTTPS-NIO listener and the HTTPS-NIO sender support the following two parameters. The above mentioned classes are available in the synapse-nhttp-transport.jar bundle.plus the parameters in the following table. The sender can also verify certification revocation.
Transport Parameters (Common to both receiver and the sender):
Parameter Name | Description | Requried | Possible Values | Default Value |
|---|---|---|---|---|
keystore | The default keystore to be used by the receiver or the sender should be specified here along with its related parameters as an XML fragment. The path to the keystore file, its type and the passwords to access the keystore should be stated in the XML. The keystore would be used by the transport to initialize a set of key managers. | Yes | <parameter name="keystore"> | |
truststore | The default trust store to be used by the receiver or the sender should be specified here along with its related parameters as an XML fragment. The location of the trust store file, its type and the password should be stated in the XML body. The truststore is used by the transport to initialize a set of trust managers. | Yes | <parameter name="truststore"> | |
customSSLProfiles | The HTTPS NIO transport |
...
supports the concept of custom SSL profiles. An SSL profile is a user defined keystore-truststore pair. Such an SSL profile can be associated with one or more target servers. |
...
For example, when the HTTPS sender connects to a target server, it will use the SSL profile associated with the target server. If no custom SSL profiles are configured for the target server, the default keystore-truststore pair will be used. Using this feature the NIO HTTPS sender can connect to different target servers using different certificates and identities |
...
. The given example only contains a single SSL profile, but there can be as many profiles as required |
...
Parameter Name | Description | Requried | Possible Values | Default Value | ||
|---|---|---|---|---|---|---|
customSSLProfiles | Define one or more custom SSL profiles and associate them with . Each profile must be associated with at least one | target server. If a profile should be associated with multiple target | servers, the server list should be specified as a comma-separated | No | <parameter name="customSSLProfiles> |
Verifying certificate revocation
| Anchor | ||||
|---|---|---|---|---|
|
The HTTPS-NIO transport sender can verify with the certificate authority whether the certificate is still trusted before it completes the SSL connection. If the certificate authority has revoked the certificate, the connection will not be completed. To enable this feature, add the CertificateRevocationVerifier parameter to the sender as follows:
| Code Block |
|---|
<transportSender name="https" class="org.apache.synapse.transport.nhttp.HttpCoreNIOSSLSender">
...
<parameter name="CertificateRevocationVerifier">true</parameter>
</transportSender> |
When this parameter is set to true, Synapse attempts to use Online Certificate Status Protocol (OCSP) to perform the verification with the certificate authority at the handshake phase of SSL protocol. If OCSP is not supported by the certificate authority, Synapse uses Certified Revocation Lists (CRL) instead. The verification process checks all the certificates in the certificate chain.
The response from the certificate authority includes the verification and the duration for which the verification is valid. To prevent the performance overhead of continuous HTTP calls, this verification response is cached for the duration specified by the certificate authority so that subsequent verification calls are not needed until the response has expired. There are two Least Recently Used (LRU) in-memory caches for OCSP and CRL, which are automatically managed by a dedicated CacheManager thread for each cache. These CacheManagers update expired cache entries and maintain the LRU cache replacement policy.