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.
anomalydistinction 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.
- 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?.