I have created a Public Cert for my server with abc.com and imported it into my clients trustore, But I'm using cde.com to invoke my application which resides on the server. cde.com resolves to abc.com with auto domain resolution (with a DNS). So my question is which hostname I should use for HostName verification. I think as per the specification [1] I should use cde.com to do the verification. Is my understanding correct?
Related
We are one application in a larger environment and a client for some data interface, using Websphere MQ 8.x. Our application is a Java EE application running on a WildFly 9 which uses a resource adaptor (wmq.jmsra.rar) which is deployed together with the EAR file in the same AS. We interact with the MQ Server in both directions. So we have on the one hand some MDBs (which are due to historical origins still in EJB 2.x format without annotations) listining to some queues and which are configured by the ejb-jar.xml deployment descriptor, containing the activation config properties destinationType, channel, queueManager, hostName, username, password. On the other hand we have a sender which lookups a queue connection factory and a queue via JNDI and creates a connection.
Now we have the requirement with a newly established MQ server to communicate via SSL and a client certificate. We got such a certificate from the server people for our machine. So my questions are:
What has to be done to make it work with the setup described above?
Is this possible purely by configuration and thus transparent for the application or has the application to specifically use SSL, present the certificate or something similar?
Does this conflict with any other keystore already used by some other part of the application?
Is some additional IBM MQ software needed to make it work? (Our client is just the RAR, no software is installed and no MQ server on our side should be established.)
Update: I went for setting the global JSSE properties for the VM as it solved my problem as a start.
It was necessary to set the following parameters:
-Djavax.net.ssl.trustStore=<location of trustStore>
-Djavax.net.ssl.keyStore=<location of keyStore>
-Djavax.net.ssl.keyStorePassword=<password>
Additionally, since I am using non-IBM VM, there was the following paramter to set:
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Then, it was necessary to set the cipher suite property on the RAR configuration in standalone-full.xml together with the other connection parameters of my WildFly installation:
<resource-adapter id="wmq.jms.rar">
...
<connection-definitions>
<connection definition ...>
<config-property name="sslCipherSuite">xxx</config-property>
...
</resource-adapter">
And finally, the MDBs listining on the queues also had to be configured to use the cipher suite, so in my case I had to add that in the ejb-jar.xml by adding for each MDB:
<activation-config-property>
<activation-config-property-name>sslCipherSuite</activation-config-property-name>
<activation-config-property-value>xxx</activation-config-property-value>
<activation-config-property>
OP stated in the comments that they use OpenJDK 8 and are using the IBM MQ v9.0.0.1 resource adapter, both of the following known problems are fixed in that release, but putting this information here for the benefit of others who may not yet be at a release where these are fixed:
APAR IV66840: TLS cipherspecs in non-IBM JREs were not supported until 8.0.0.2.
APAR IT10837: WildFly 9 may hit another issue if using a non-IBM JRE in finding the KeyStore that contains the client cert, this is fixed in 8.0.0.5.
The resource adapter includes the MQ functionality to support TLS but uses the underlying JSSE for the actual encryption.
Based on RFC 5246 it suggests that the TLS Client should only return a cert that is suitable based on the the server sending "A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format.", this would mean that if the certs in your keyStore for the different uses (ex: existing non-MQ certs and MQ certs) are not signed by the same CA chain, and the various TLS servers you connect to do not accept certs from the CA of other certs in your key store (ex: existing non-MQ certs and MQ certs) then JSSE will return the appropriate cert to each.
For example if existing non-MQ certs are signed by a Internal CA and the MQ cert is signed by another company's CA, it is highly unlikely that the MQ company would trust your internal CA certs, conversely it is unlikely that your other non-MQ TLS servers you connect to would trust the other company's CA. Since JSSE would return only a cert that was trusted by the remote server they should not impact each other. You would just need to add the MQ cert to your existing key store.
Quotes from the relevant sections of RFC 5246 are at the bottom of this post.
#a_cornish_pasty answer to your question "Use specific keystore for JMS" is also an alternative as it would allow you to specify a separate key store from what the rest of Wildfly uses, this key store could have ONLY the MQ cert, so no chance of causing an issue with the existing key store and certs.
RFC 5246 Section 7.4.4 states the following:
7.4.4. Certificate Request
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the ServerKeyExchange
message (if it is sent; otherwise, this message follows the
server's Certificate message).
It then goes on to state:
certificate_authorities
A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
RFC 5246 Section 7.4.6 states the following:
7.4.6. Client Certificate
When this message will be sent:
This is the first message the client can send after receiving a
ServerHelloDone message. This message is only sent if the server
requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a
length of zero. If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert. Also, if some aspect of the certificate chain was
unacceptable (e.g., it was not signed by a known, trusted CA), the
server MAY at its discretion either continue the handshake
(considering the client unauthenticated) or send a fatal alert.
It then goes on to state:
If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs.
I am using the great Charles Web Proxy do make a reverse proxy and debug an exchange between my client and a secure server.I accepted the Charles certificate as a trusted authority and it works generally very well when using it in Proxy Mode, the problem is when I try to make a reverse proxy.
I am using an external library over which I have no control that uses an HttpUrlConnection and lets me specify the URL. Following the Charles documentation, I set my URL to https://mybox.test.com:100 (note that I used a hostname, added to my host file, instead of localhost in the hope that I can have a valid certificate).
The problem is that as part of the Https validation, HttpUrlConnection verifies the host name (mybox.test.com since it is pointing to my reverse proxy) against the one in the certificate (the one of the secure site I am connecting to). Obviously that does not match and causes a
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching localhost found.
I realize that Charles cannot generate a certificate for mybox.test.com, since it only listens to a particular port and has no knowledge of the URL used in the HttpUrlConnection. I do not see how it could generate a correct certificate that would be accepted.
My question is: is there a better way to use a reverse proxy with Https or do I need to disable the host name and certificate validation ?
I built a Web-Service application in Jdeveloper 11.1.1.7 and deployed it on weblogic 10.3.6 with all Key-store and SSL configuration.
SSl Configuration:
Use Server Certs : Checked
Two Way Client Cert Behavior: Client Certs Not Requested. [That is means it is one-way ssl.
Correct me if that wrong]
SSL Listen Port Enabled: Checked
Key-store Configuration:
Custom Identity and Custom Trust. The file path has been specified for those custom key store
A sample client application has been created and everything seems to be fine; I mean the client can not access the server application without specifying the trust store file location where the server certificate is stored and it is trusted at the client end.
By the server certificate I mean the same certificate that has been configured in server Key-store Configuration
for your information the client application referring to trust store as follow:
System.setProperty("javax.net.ssl.trustStore",[Trust-store location goes here]);
System.setProperty("javax.net.ssl.trustStorePassword", [password goes here]);
Till now nothing wrong. Next is the problem details:
For the purpose of testing I tried to access the deployed web-service application using the SoapUI (open source software). What is confusing is the request has been sent, accepted at the server and proceed without specifying any thing for server certificate nor trust store location in SoapUI project configuration !!
Why the SOAP request has been accepted from SoapUI without referring to server certificate? The request should be rejected in this case.
My experience with SoapUI is that it is quite lenient. For example, if it doesn't check if the CN of server certificate matches the fully qualified domain name in the URL. In your case, your server most likely uses a CA signed certificate. Most of the root and intermediate certificates of well known CA's (e.g. VeriSign/Symantec) are already included in the default truststores for most systems. If your server had used a self-signed certificate, then SoapUI would have incurred SSL error unless you import the self-signed certificates into the truststore of the host where SoapUI is running.
We have configure a Big F5 load balancer virtual server for a particular IP address which redirects incoming https requests to several Windows servers where there is functionality to generate responses.
I am using SoapUI to test access to these windows servers via the IP address of virtual server in the Big F5.
Using Server and Client certificates generated by the organization where the we have also this set up and sending requests via SoapUI I get the predicted responses back.
The business requirements call for Commercially signed certificates by Thawte.
We created a Certifcate Servcice Request (CSR) to generate a Server certificate and its private key and then we had it signed by Thawte, and also requested a Client Commercially signed certificate from Thawte.
We loaded both certificates in SoapUI client and the Big F5 load balancer but we attempting to test the requests we get the "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" error.
My questions are:
How can I monitor where exactly the 2 way SSL handshake is terminated
The actual reason what exactly is happening?.. why using commercially signed certificates this does not work now?
Any replies are welcome. Thanks.
However when we swithch Serverto commercially signed by Thawte
This is possibly due to the Java security feature. If so you need to edit the soapui-4.x.x.vmoptions file located at soapui-4.x.x\bin folder and add -Dsun.security.ssl.allowUnsafeRenegotiation=true to the end.
You may also need to export the certificate as a pfx file and set it up in soapUI preference page. For details you can check http://geekswithblogs.net/gvdmaaden/archive/2011/02/24/how-to-configure-soapui-with-client-certificate-authentication.aspx and http://forums.devarticles.com/java-development-38/javax-net-ssl-sslhandshakeexception-received-fatal-alert-handshake-failure-11809.html .
The client is a SoapUI request that has not changed except a different client certificate
That suggests that the server doesn't trust the new client certificate, which in turn implies that the client certificate wasn't even sent because it wasn't signed by one of the server's trusted signers. Closing the connection is the server's only real option in this circumstance, as there isn't an SSL alert for it.
Make sure you have address translation on and the SNAt set to Auto Map for your VIP
I want to understand the below line
"The SSL Cert is bound to the actual host name. If you have an SSL cert for "qa.example.com", it won't work on your machine named "dev.example.com".
Questions:
How is possible to create a cert bound to a hostname?
I have a client and server model. The server is not validating the client during communication. So far I had ONE set of key and certs which is installed on multiple servers and the communication works fine.
Now we have new set of certs which is bound to a hostname. Each server has a set of certs.
When swapped the communication does not work. "Handshake failure" obtained.
What's happening here? Who validates the hostname?
The client validates the certificate returned by the server. Among the various verifications performed the client checks that the hostname embedded in the certificate matches the hostname of the server. If the hostname doesn't match the handshake fails.
This means that if your certificate was issued for qa.example.com, it won't work on dev.example.com. For the same certificate to work for both hostnames you'll need a wildcard certificate (issued for *.example.com).
The hostname is in the certificates, you need to generate new certificates with different hostnames. The certificate names is validates by the client when it attempts to establish a secure connection.