0

I've a question regarding a certificate validation error I'm getting. I'm performing an https request from one machine to another (windows machines). On the destination machine I've configured a self-signed ssl certificate for the webapp. On the the machine that is performing the request i've installed the root certificate (which was used to sign the self-signed one I installed in the other machine) in the trusted root certificate store.

The source app performs the request to that webapp hosted on the destination machine, by domain name, but its domain name is not registed with a dns server. It's simply configured locally in the hosts file of the OS. Basically it's a local dns.

But when I perform the web request, I get certificate validation errors (could not establish ssl trust). If I try to perform the request from the browser, I get the same error. But if I investigate the certificate and certificate chain, I can find all certificates are ok (both the SSL certificate used, and up the certificate chain, the root one). But I still get the validation error.

Could the fact that I'm using a local dns (via that local hosts file) be the reason for this? Thank you.

  • If it's self-signed, it can't be signed by a CA. – Stephane Jul 3 '15 at 9:38
  • Sorry, it's not signed by an official CA. I generated the rootcertificate, then I generated the server certificate used for SSL, and I signed it with the rootcertificate. I then installed the root certificate .cer file (public key only in the trusted root certificate store). And the browser, while failing to validate the certificate, in the certificate path it lists both the current one, and the root one as being ok. – danutz_plusplus Jul 3 '15 at 9:46
  • That's a private root. – Stephane Jul 3 '15 at 10:00
  • Seems we found the issue. The signature check was alright. It was a different field on the certificate that wasn't validated correctly. So, it seems to be working fine even with local dns. Cheers – danutz_plusplus Jul 3 '15 at 10:03
2

The process of establishing a full trust chain between two system using TLS is the following:

1/ Create or obtain the root CA X509 certificate. 2/ Obtain all intermediate signing authorities. 3/ generate a leaf X509 certificate and have it signed by the authority immediately higher in the trust chain (either an intermediate CA or the root CA if you're using a simple model).

On the server:

  1. Install the root CA in the trusted root certificate store (under windows, it is recommended to do so for the local computer account unless you know exactly which security principal will be used by the server app).

  2. Install all intermediate CA certificates in the appropriate store (note that, depending on the server software, you might need to create a "chained" certificate file instead containin all relevant certificates in the chain as well as the private key for the leaf) (on windows same remark as for 1/)

  3. Install the leaf certificate on the appropriate user principal store (in windows, again, typically the local computer "personal" store)

On the client:

  1. Install the root CA in the trusted root certificate store.

Note that all certificate will need to exhibit the appropriate properties to be considered valid. The hard part is that this depends a LOT on the application, the usage of the certificate and how it was generated. Typically, for TLS, the leaf certificate must have a a subject.CN field or an a entry under SubjectAltName that matches the DNS name you're using to attempt to reach it (even if you're using a HOST file). Additional requirement can be placed by the client as well (for instance, Chrome will not accept certificate with SHA-1 signatures if their validity extend beyond 01/01/2017).

All this is independent on the name resolution process: it doesn't matter if the client obtains the server's IP address through a regular DNS resolution query or from a HOST file.

  • Cool, thanks a bunch for the detailed post. It was an informative read. – danutz_plusplus Jul 3 '15 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.