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.
An anomaly 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?.
This post is now followed up at Serverfault
The CA-signed certificate was supposed to be in PEM/Base64 format. It was rather in DER format. Changing it fixed the problem.
Related
I'm using a wildcard certificate for two separate domains abc.com and xyz.com
It's a Self-Signed Cert and I'm getting NET::ERR_CERT_AUTHORITY_INVALID.
Will ignoring the warnings thrown by one domain (abc.com) cause Chrome to ignore the warnings thrown in the other domain (xyz.com) by the same certificate?
The warnings gets only ignored for the domain you've explicitly added the exception for. Otherwise bad attacks would be possible, like having a self-signed certificate with both "does-not-matter-if-secure.example.com" and "www.paypal.com" as subject alternative names and then using the fact that the user adds an exception for the first unimportant site to mount a man in the middle attack against www.paypal.com.
I am looking for some help, trying to satisfy my curiosity by figuring out why Chrome 46.0.2490.80 won't let me access https://www.evernote.com, while Firefox works fine. Chrome was working fine too, until 2 days ago, but now it throws the NET::ERR_CERT_REVOKED error.
So I got curious - is the certificate actually revoked? Well let's check...
I opened the certificate dialog and exported the certificate (evernote.pem), and it's issuer chain (evernote-chain.pem):
Grab the OCSP Responder URI from the certificate:
$ openssl x509 -noout -ocsp_uri -in evernote.pem
http://ss.symcd.com
Let's check the certificate status now:
$ openssl ocsp -no_nonce -issuer evernote-chain.pem -CAfile evernote-chain.pem -cert evernote.pem -url http://ss.symcd.com
Response verify OK
evernote.pem: good
This Update: Dec 16 09:14:05 2015 GMT
Next Update: Dec 23 09:14:05 2015 GMT
So, the certificate is not revoked, which is why Firefox works correctly. So what's going on with Chrome? Why does it think that this certificate is revoked?
I did notice another detail, which may or may not be important - I don't really understand it. The chain of certificates in Chrome is different from the chain obtained from Firefox, or from openssl. Chrome is seeing the following chain:
|- Class 3 Public Primary Certification Authority (Builtin Object Token, self-signed)
|---- VeriSign Class 3 Public Primary Certification Authority - G5 (35:97:31:87:F3:87:3A:07:32:7E:CE:58:0C:9B:7E:DA)
|------- Symantec Class 3 Secure Server CA - G4
|---------- www.evernote.com
Firefox and openssl see this instead:
|- VeriSign Class 3 Public Primary Certification Authority - G5 (18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A, self-signed)
|---- Symantec Class 3 Secure Server CA - G4
|------- www.evernote.com
I am not sure how to interpret this. It seems VeriSign Class 3 Public Primary CA is almost the same in Chrome, except instead of being self signed, it is replaced with something that looks exactly like it, but signed by this other "Builtin Object Token" in Chrome... What does this mean? Could it have anything to do with the problem I am experiencing?
UPDATE:
The first part of the question has been answered below. The reason why the site stopped working recently is b/c Google decided to distrust the “Class 3 Public Primary CA” root certificate, as explained here:
https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html
and here: https://code.google.com/p/chromium/issues/detail?id=570892
Since the decision was reversed for now, the problem can be fixed by getting the latest CRLSet in chrome://components/
However, the second part of the question remains:
Where is Chrome getting it's certificate chain from?
Firefox, openssl and https://www.digicert.com/help/, all show this same chain:
VeriSign Class 3 Public Primary Certification Authority - G5
18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A
Symantec Class 3 Secure Server CA - G4
51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF
www.evernote.com
18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91
Yet Chrome is using:
Class 3 Public Primary Certification Authority
70:BA:E4:1D:10:D9:29:34:B6:38:CA:7B:03:CC:BA:BF
- This is the no longer trusted Root CA
VeriSign Class 3 Public Primary Certification Authority - G5
35:97:31:87:F3:87:3A:07:32:7E:CE:58:0C:9B:7E:DA <- WTF?!
Symantec Class 3 Secure Server CA - G4
51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF
www.evernote.com
18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91
The only explanation I can think of is that the "evil" version of the "VeriSign Class 3 Public Primary Certification Authority - G5" certificate is already in my certificate store somewhere. It has exactly the same CN and "Authority Key Identifier" as the "good" version, but it references a CA that is no longer trusted by Chrome. I have verified this assumption by direct comparison of the certificate in question between Chrome and Firefox. They are identical, and must generated using the same private key (or they wouldn't both be correctly verifying the signature on the Symantec cert), but one is self signed (the good one), and the other is not (the evil one).
So where is this certificate store/cache, which Chrome is using? Is it internal, or would it be system wide on Ubuntu? I am pretty sure that if I was to find and clear this cache, www.evernote.com would send me a full certificate chain during the next TLS handshake, and everything would right itself (this seems to support my theory: https://security.stackexchange.com/questions/37409/certificate-chain-checking).
But how do I blow away all of my cached certificates in Chrome?
Not sure what it all means, but the answer is there:
https://code.google.com/p/chromium/issues/detail?id=570892
and
https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html
Google revoked a Symantec certificate from Google products, but they have suspended the revocation following the type of issues you're describing (which I also experienced). Quoting the Chromium ticket:
First, the good news is the change has been temporarily reverted, and you should find access restored. You can force an update by going to chrome://components and under CRLSet, clicking "Update". You should have version 2698 or later to fix this issue.
To answer the second part of the question, i.e. why Chrome finds a different trust path than the others.
The server is actually sending the following certificates to the client:
www.evernote.com
18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91
Symantec Class 3 Secure Server CA - G4
51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF
VeriSign Class 3 Public Primary Certification Authority - G5
25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd
Note that the serial number on the last certificate is different to both serial numbers you have in your text, which means that there are several certificates with the same subject and public key out there which all can be used to built the trust chain.
Depending on the certificates you have installed in your system and the SSL stack used for validation different trust path are possible. For instance with openssl 1.0.1 on Ubuntu 14.04 it will also use the longer trust path you've seen with Chrome, i.e. the one which ends with the locally installed CA "Class 3 Public Primary Certification Authority". With OpenSSL 1.0.2 the handling of multiple trust path was changed and it will now prefer the shorter path which actually ignores the "VeriSign Class 3 Public Primary Certification Authority - G5" sent by the server and instead ends the trust chain in the locally installed version of a similar certificate (same public key and subject, different serial number).
The version of Chrome you've used had the specific Symantec certificate removed and now one of the possible trust path contains a revoked certificate, which means that the path cannot be trusted any longer. The bug is probably that Chrome then uses this result as the final result instead of looking for a different trust path which still would be valid.
From what I understand, Chrome uses certificates/cert store of the local machine, but Firefox uses its own in-built cert store. This would explain the discrepancy between the browsers.
I've got some trouble with expiring client certificates on some project I'm working on, occuring in Firefox 21 and versions below.
The environment: There are client-pcs, which have one single client certificate for each of them. Those client certificates were installed by using the PKCS12 file format with export password set. The clients are calling a site with domain 'a.somedomain.net', every server request has 'b.somedomain.net' as target. The certificates are valid for '*.somedomain.net'. So far, so good, everything's fine.
Now they're expiring, so I wanted to have some update mechanism doing a quiet, no-user-action-required update of the certificates. I am checking the $_SERVER['SSL_CLIENT_V_REMAIN'] variable and performing an update if the number of remaining days is below a predefined value. That also works.
In case an update is required, I'm doing some http redirect to a script located at "b.somedomain.net". The form includes all DN data HTML5 browsers need for creating the public/private key pair and sending the public key to the form action url. That also works.
Now the server's signing the certificate via OpenSSL/PHP and returns the certificate with correct headers for recognization by the browser. But then FF tells me "This personal certificate can't be installed because you do not own the corresponding private key which was created when the certificate was requested."
The private key stays behind FFs doors, I only get the public key from FF, OpenSSL is fine with it and throws no errors. What am I doing wrong?
If there's more information needed, please comment.
Thanks in advance.
in the other Question Generating client side certificates in browser and signing on server">Generating client side certificates in browser and signing on server there is an Answer with an Link to crosskeygen.js and the HTML Templates HTML-Templates that show how it works.
For me this was an great help.
I've got a self-signed certificate for multiple domains (let's say my.foo.bar.com & yours.foo.bar.com) that I've imported using Keychain Access but Chrome will still not accept it, prompting me for verification at the beginning of each browsing session per domain.
The Certificate was generated using the x509v3 subject alternative name extension to validate multiple domains. If I navigate to the site before I import the certificate, I get a different warning message than after importing. Attached below is an image of the two errors (with the top being the error before imported)
Is there any way to accept a self-signed multi-domain certificate? I only get warnings in Chrome, btw. FF and Safari work great (except those browsers suck ;) )
UPDATE: I tried generating the cert both with the openssl cli and the xca GUI
The problem is that you're trying to use too broad a wildcard (* or *.com).
The specifications (RFC 6125 and RFC 2818 Section 3.1) talk about "left-most" labels, which implies there should be more than one label:
1. The client SHOULD NOT attempt to match a presented identifier in
which the wildcard character comprises a label other than the
left-most label (e.g., do not match bar.*.example.net).
2. If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
I'm not sure whether there's a specification to say how many minimum labels there should be, but the Chromium code indicates that there must be at least 2 dots:
We required at least 3 components (i.e. 2 dots) as a basic protection
against too-broad wild-carding.
This is indeed to prevent too broad cases like *.com. This may seem inconvenient, but CAs make mistakes once in a while, and having a measure to prevent a potential rogue cert issued to *.com to work isn't necessarily a bad thing.
If I remember correctly, some implementations go further than this and have a list domains that would be too broad for second-level domains too (e.g. .co.uk).
Regarding your second example: "CN:bar.com, SANs: DNS:my.foo.bar.com, DNS:yours.foo.bar.com". This certificate should be valid for my.foo.bar.com and yours.foo.bar.com but not bar.com. The CN is only a fallback solution when no SANs are present. If there are any SANs, the CN should be ignored (although some implementations will be more tolerant).
Due to a limitation on our SMTP provder's side, we're having to use System.Web.Mail (deprecated), which is a wrapper around CDOSSYS.
Because we'd like to avoid having to change multiple configurations if we switch providers at a later date, we set up an internal alias for our providers FQDN.
So, mailrelay.ourdomain.com -> mailrelay.provider.com.
When I try to connect to either our alias or the provider's IP, a COM error bubbles up: "The transport failed to connect to the server." If I connect to the provider's true FQDN, everything works as expected.
I've looked in Wireshark, and I can see the certificate being requested, but not much happens after that.
I'm wondering if anyone knows if CDOSSYS checks to make sure the requested host name matches the FQDN on the certificate and fails if it doesn't match.
I've tried searching for an answer to this question, but I can't seem to find it.
I can't find a definitive answer, but from what I can tell, yes, CDOSYS does require a certification to match an SMTP server's FQDN when using SSL.