Since I updated chrome to ver 58.xx I can’t access the server administraton page anymore.
chrome 57 worked fine. Opera 44 works fine. IE 11 works fine. Firefox 53 needs an exception rule, but works.
NET::ERR_CERT_COMMON_NAME_INVALID
[missing_subjectAltName]
I found this: As of Chrome 58 SSL certificates must have a “Subject Alternative Name” (SAN) field, “Common Name” (CN) is not sufficient anymore. This breaks many self signed certificates on dev machines.
But I have an alternative name: *.domain.tld and the common name is equal to the server name.
Just installed Chrome Version 58.0.3029.96 (64-bit).
I have tested with NS 6.8 and 7.3. From LAN and WAN.
It works without problems with my self-signed certificate.
I have tested with the IP and with the domain name. Of course, with the exception rule [ADVANCED -> Proceed to … (unsafe)].
Windows 10 Pro/64 bit.
Try to edit again your self-signed certificate.
After that, look in message log (on NS) to see if there is any error regarding self-sign certificate.
EDIT:
Give me 15 minutes to check also on Win 7 Pro/64 bit.
I generated a new certificate, but didn’t help.
After clearing squid cache, I can access admin interface again.
But one thing remains: chrome complains about security with admin-interface page.
while opera
and IE 11
don’t do.
Everything else seems to work again. It’s a bit confusing.
I found the solution in creating manually a new certificate. Not with ns-gui.
If I use the certificate created by ns it doesn’t because this crt doesn’t have the “X509v3 Subject Aternative Name”.
I followed this:
and got a cert with X509v3 SAN :
After enabling it in GUI I got a trusted GUI
I think this should be implemented in the GUI-routine to create certificates.
Yes, it needs just the SAN. After applying these certificates everything was o.k. again.
PS: I choose the SAN equal to the common name. Don’t know if this is mandatory, but this works.
No it’s not. OpenSSL configuration is not currently modified, so we need to add a template or a similar logic.
I would like to pointing out that a certificate with a subject aternative name is still not valid, since the certificate is self-signed.
Also, current certificate is still functional with Chrome 58, but , of course, you have the usual warning for self-signed certs.
Yes, that’s right. You still have to add this cert to the trusted authorities in certificate management.
So this cert is only for “intranet use” valid.
The user creating a self signed certificate will need to manually add that cert to their respective cert list within chrome, that’s what I do.
The modifications I made are to the openssl.cnf file which isn’t managed by nethserver. A template should he created for that file under ca-certificate module. This would ensure the self signed cert includes the SubjectAltNames.