You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today Liberty has the ability to enable hostname verification on for secure connections using httpsURLConnections. While using httpsURLConnection accounts for a lot of outbound call it does not cover all.
example of current configuration:
<sslDefault httpHostNameVerification=“true”/>
The proposed change is to make hostname verification configurable at the SSL configuration level. That means hostname verification will be performed for all outbound connection using the specified SSL configuration.
For this to work the transportSecurity-1.0 feature needs to be enabled. The suggested configuration will look something like this:
Hostname checking will be performed by the JDK by the TrustManagers following the server identity that looks at the server's certificate's SubjectDN or SubjectAltName (SAN) information.
Since the checking can look for SAN information in a certificate I'm also suggesting we add the server hostname to the SubjectAltName extension of the default certificate. The SubjectAltName part of the certificate will contain the server's hostname in the DNSName attribute by default, something like this:
Since we are adding information to the default certificate it would probably be a good idea to expose customizing of SubjectAltName information through the securityUtility, createSSLCertificate command.
In the design meeting issues meeting it was suggested that I change the configuration name from enableHostnameVerification to verifyHostname. The description above has already been updated.
Today Liberty has the ability to enable hostname verification on for secure connections using httpsURLConnections. While using httpsURLConnection accounts for a lot of outbound call it does not cover all.
example of current configuration:
The proposed change is to make hostname verification configurable at the SSL configuration level. That means hostname verification will be performed for all outbound connection using the specified SSL configuration.
For this to work the transportSecurity-1.0 feature needs to be enabled. The suggested configuration will look something like this:
Hostname checking will be performed by the JDK by the TrustManagers following the server identity that looks at the server's certificate's SubjectDN or SubjectAltName (SAN) information.
Since the checking can look for SAN information in a certificate I'm also suggesting we add the server hostname to the SubjectAltName extension of the default certificate. The SubjectAltName part of the certificate will contain the server's hostname in the DNSName attribute by default, something like this:
#1: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: myhost.austin.ibm.com
]
The text was updated successfully, but these errors were encountered: