0

There is a non-public-facing application. I am trying to make sure that there are no HTTPS-related warnings/errors.

  • The error I receive after putting the certificate with SAN field (signed by a trusted CA) is that the web application won't load at all i.e. exclusively Google Chrome (latest) throws ERR_CONNECTION_RESET. This is the only error I get. Firefox/Safari works fine.

  • In contrast, a self-signed certificate with SAN field gives no broken HTTPS error (SAN-related warning); I am going to not talk about the other error I get because of the certificate being self-signed.

  • A anomaly distinction I see is that the the root certificate (one level up; there are 2 levels of depth in total) in the certificate chain, in case of trusted CA-signed certificate, is not having any SAN field in it.

  • I have not tried fixing that part (unsure if that can be fixed at all, so wouldn't talk much) i.e. attaching SAN field to root certificate. I want to talk about it here before taking more actions from my side.

  • The application (for which the certificate with SAN is needed) is non-public i.e. the DNS entry of the SAN field contains a domain address which isn't publicly resolvable (shouldn't be an issue till the point my browser can resolve it?).

Any kind of insight is greatly helpful. Please suggest if clarification is needed.

P.S.

Some updates:

  • I wanted to test whether an openssl-generated self-signed CA with X509 extensions (SAN, Key Usage) is going to give an error. Interestingly, it did not gave that Chrome error. It works fine as it should (apart from the self-signed error, which isn't a concern atm).
  • Upon opening the certificate file in Windows OS and checking the extensions, Key Usage for self-signed certificate is Key Encipherment, Data Encipherment (30) and it is marked non-critical, however, for CA-signed (Microsoft Active Directory Certificate Services) it is Digital Signature, Key Encipherment (a0) and it is marked critical.
  • To rule out if this could be an issue with Key Usage being marked as critical, I generated a self-signed certificate (again using openssl) with that X509 extension marked as critical. Interestingly, it worked fine as well. In this case as well, the only error I get was of the certificate being self-signed.
  • When a requested signed-certificate is returned back by the CA, there are a bunch of other X509 non-critical extensions being added to the certificate. I do not see that as a problem at this point, however, it could be a reason where a critical Key Usage extension alongwith those non-critical extensions might open a scope of failure.
  • For the TLS handshake, there is no reply from the server-side at all.

Is it fair to think that this could be an issue around any involved encoding in the CA-signed certificate?.

Avineshwar
  • 19
  • 3
  • I don't see how it is an anomaly that the intermediate certificate (you said root, but the your description indicates you meant intermediate) does not have a SAN extension. It's rather the opposite, it would be strange if it had such an extension. The same applies for the actual root certificate as well, fwiw. – Håkan Lindqvist Feb 10 '18 at 10:17
  • Any errors/warnings logged by the httpd? Are you absolutely positive that you are requesting the same URL when it works and when it does not? Based on the "the server just hangs up during the TLS handshake" description I would suspect it may not find any suitable certificate to present to the client or something to that regard. – Håkan Lindqvist Feb 10 '18 at 10:23
  • @HåkanLindqvist It is not anomalous. I fixed it. I agree having SAN extension would be out of normal in root certificates. There is no intermediate CA/certificate. The certificate chain has 2 certificates (1 is in question and the other is the root certificate) in total. I'm absolutely positive about requesting the same URL. I suspect the same but it is new for me in a sense that what TLS handshake-related data could the client probably send to the server to which server responds with a hang-up i.e. no data sent back, when the only difference is certificate either has SAN or it does not?. – Avineshwar Feb 10 '18 at 11:34
  • @HåkanLindqvist I also suspect if it has to do something with encoding of X509 extensions in CA-signed certificates (CA is Microsoft AD CS) when compared with the self-signed openssl-generated certificates with extensions. – Avineshwar Feb 10 '18 at 11:45

2 Answers2

2

The CA-signed certificate was supposed to be in PEM/Base64 format. It was rather in DER format. Changing it fixed the problem.

Avineshwar
  • 19
  • 3
-2

Google and Symantec are currently fighting a little bit Chrome’s Plan to Distrust Symantec Certificates Is your official certificate from an Symantec root ca (or any chain component)? Maybe than your certificate is alredy halfly untrusted. In that case, in googles opinion, you should go to a more trustful ca.

Serpen
  • 27
  • 2
  • `ERR_CONNECTION_RESET` suggests there is a technical problem, not a policy decision by the client. Also, it doesn't match the timeline, see https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html – Håkan Lindqvist Feb 10 '18 at 10:05
  • A questionable/half trust situation (whatever may be the reason) results in a broken HTTPS not a technical glitch (usually the reasonings are around mis-configurations or application-side shortcoming, which seems to be the case) – Avineshwar Feb 10 '18 at 11:39