[SOLVED] NET::ERR_CERT_COMMON_NAME_INVALID in Chrome with new Certificate
-
Hopefully this will save some time for someone else who has got this issue.
After changing WebGUI certificate, I found that Firefox and Edge both logged into pfsense with the new cert no problem. Iexplore logged in but with an orange padlock, and Opera wouldn't login and complained about the cert. The main issue was with Chrome (which I use exclusively to admin my pfsense box). It just reported
NET::ERR_CERT_COMMON_NAME_INVALID and wouldn't go any futher.
The problem is described here:
https://support.google.com/chrome/a/answer/7391219?hl=enand the fix is to ensure you put your FQDN in the Alternative Name field as well as the common name
-
….
The problem is described here:
https://support.google.com/chrome/a/answer/7391219?hl=enand the fix is to ensure you put your FQDN in the Alternative Name field as well as the common name
The real fix is (as mentioned):
If needed, until Chrome 65, you can set ….
… so the will remove this 'bug' ....
A better fix is to use this very young browser for "testing purposes only". The "what-ever-you-type-and visit-will-be-taken-over-to-Google" part works great, for the rest : still to many issues every time.
"' Remember the early IE days ..... never ever kidd-browsers anymore - take a stable (why not : neutral) one.Btw : normally, you balance "example.tld" in the Common name - and all the web, www, pop, smtp, imap, nsX, ftp, etc in the "subjectAlternativeName" (I might be worng here, but that always worked for me ;) )
(my opinion of course ;) ) -
I experienced the same issue after installing v2.4-RC. Chrome and Edge generated security certificate errors. I couldn’t log into GUI with Edge. I could log into GUI with Chrome however random security certificate errors were generated during configuration. I did not test Firefox. Certificate errors did not appear after entering FQDN and GUI IP address.
No errors were generated however upgrading from v2.3.4 to 2.4-RC.
-
… Certificate errors did not appear after entering FQDN and GUI IP address.
Well, the FQDN should be part of the certificate. That's the whole idea actually. Without it, errors will be thrown. That a feature, not a bug ;)
A "certificate", using 2.3.4 or 2.4.0.x, stays the same.
Who generated this certificate ?
Goto pfSenese => System => General Setup
What is your Host name ? Domain ? Is this FQDN part of the certificate ?
What names (Subject and Alternative Subject) are listed in your certificate ?Btw : putting an IP in a certificate : most CA will just refuse that. An IP in a certificate as a "DNSName' ( Subject and Alternative Subject ) can be useful if you broke DNS first.
Where is your certificate came from ?
(and sorry, do try the browser that works and leave these 'new' browser for what they are - let others 'debug' them except if you have the time and knowledge to do so) -
I did not say it was a bug.
It was a self-signed certificate.
-
If you happened to have a self-signed certificate that was created before the change linked below the newer browsers definitely didn't like it because they now require the FQDN of the system in the SubjectAltName field of the certificate.
-
@kpa:
If you happened to have a self-signed certificate that was created before the change linked below the newer browsers definitely didn't like it because they now require the FQDN of the system in the SubjectAltName field of the certificate.
Which is where we came in :)
I don't think I will start any arguments about whether Chrome is an upstart baby browser or fully mature 9 year old browser which eclipses all other browsers by market share
-
If you make a new cert now (on 2.3.4, 2.3.4-p1, 2.4 or later) it automatically adds your common name field value as the first SAN.
If you put it in again it will ignore it in the SAN field and only add it once.
-
If you make a new cert now (on 2.3.4, 2.3.4-p1, 2.4 or later) it automatically adds your common name field value as the first SAN.
If you put it in again it will ignore it in the SAN field and only add it once.
Sounds like a good solution/workaround. Thanks Jim.
-
@kpa:
If you happened to have a self-signed certificate that was created before the change linked below the newer browsers definitely didn't like it because they now require the FQDN of the system in the SubjectAltName field of the certificate.
Which is where we came in :)
I don't think I will start any arguments about whether Chrome is an upstart baby browser or fully mature 9 year old browser which eclipses all other browsers by market share
I meant newer versions of the mainstream browsers, not any of the completely new browsers or new forks of the existing ones. Chrome did what they had to with the validation requirements, hence the issue.
