HTTP Client with server using self signed cert - truststore seems to not handle host verification

[Manish Kumar]

My HTTP Client connects to a server that's using self-signed cert. I am providing a PEM file containing the self-signed server cert.

options.setPemTrustOptions(new PemTrustOptions().addCertValue("buffer containing the PEM format cert"));

It seems that Host Verification is still complaining. If I set options.setVerifyHost(true) then everything works fine, but I don't want to do it because we are already providing the trusted cert. 

Caused by: java.security.cert.CertificateException: No name matching localhost found
   at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:231)

Am I missing something?

[Julien Viet]

you are saying that if you setVerifyHost(true) it works, which implies that with setVerifyHost(false) it does not work. That sounds weird, can you check this assertion ?

besides what is the self signed certificate CN ?

 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/fd1f4fa6-eb9f-4f4c-92ac-336d28cb1bd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Lehmann]

The cert checking implementation is delegated to the normal java implementation, there should be no difference from e.g. the cert check in apache hc.

If you have host checking==true, the cert has to have cn=localhost or have localhost in a SAN (resp. the server name you are connecting to), if you have host checking==false, the hostname is not checked, but if the cert is valid based on the trust store you have configured.

If you have set host checking==true and it works, that would be strange, I expect that behaviour from host checking==false.

[Manish Kumar]

I am sorry. By mistake I said that options.setVerifyHost(true) works. Actually it's other way around -  options.setVerifyHost(false).

I apologies.

I thought that if I am providing remote server PEM cert in trust-store then it should take care of everything. When I am using REST template and provide the KeyStore formatted password protected file(I added PEM certs into a keystore using Java KeyStore API) then it works. I am thinking if I providing PEM truststore doesn't handle host validation. Maybe I should generate JKS out of PEM files and provide the JKS as truststore.

[Manish Kumar]

I agree that my knowledge around certificates etc is limited. Sorry if I have said something stupid. I just realized that keystore created by java API is nothing but JKS format.

Having said that, I tested with providing the JKS truststore and still fails with same host verification error. If I use Spring REST template and same JKS, SSL handshake works fine.

I agree that you are using underlying Java implementation, and there might not be anything that needs to be fixed in Vertx.

[Julien Viet]

Vertx provides an utility class for generating self signed certificate:

io.vertx.core.net.SelfSignedCertificate.create(“localhost”) will generate PEM files that you can get with privateKeyPath() and certificatePath() and reuse.

Julien

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/21b94201-57f5-475b-bf58-08e36d87e79c%40googlegroups.com.

[Manish Kumar]

I can't use that API from Vertx. This is what we are suppose to do.

1 - During installation our app connects to remote server to checks if remote server is using the self-signed cert, it prompts the details of remote server's self-signed certs.

2 - Person doing the installation will review the self-signed certs from remote server, and stop/continue the installation if they trust the remote certs.

3 - If self-signed certs from remote server are accepted then our app should create JKS/PEM truststore, and start with the app with the generated trust-store. This should allow the app to do successful SSL handshake since the remote server certs are provided as truststore.

That's the reason we can't use Vertx's API to generate the self-signed certs.

[Alexander Lehmann]

I would expect that the certificate will not work with a normal browser either when it doesn't have the correct hostname. If you are required to check the cert, setting hostname check == false should be correct, it will still fail when the cert is not correct

[Manish Kumar]

I agree on it. If remote server's certs are already provided in trust-store to the connecting client, and host-name verification during SSL handshake becomes less of an importance.