Chrome 58 doesn't work with nethserver

NethServer Version: NS 6.9 final
Module: proxy

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.

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.

Anyone else whose having this problem?? :disappointed_relieved:

1 Like

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)].

1 Like

Hi Gabriel, thanks for reply.

Are you on Win 7 or Win 10. I’m on Win7 pro 64 bit.

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.


Give me 15 minutes to check also on Win 7 Pro/64 bit.

1 Like

I’m on Win 7 Pro/64 bit now.

It works fine.

I think is something wrong with your self-signed certificate.

o.k. will try to generate a new one.

Fedora 25, Chrome version 58.0.3029.81 (64-bit), no problem so far.

I generated a new certificate, but didn’t help. :worried:
After clearing squid cache, I can access admin interface again. :slight_smile:
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. :confused:

1 Like

@giacomo I found an article that chrome drops support for sha-1

Nethserver self signed certificate shows fingerprintalgorithm: sha-1. Can this be a rpoblem?

I don’t think so, sha-1 support has been dropped in Chrome 56.
Also my Chrome states that NS certificate is “PKCS #1 SHA-256 With RSA Encryption”

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.



Generated new certificates on a NS 6.9 VM with X509v3 SAN and did

db configuration setprop pki CrtFile '/path/to/cert/pem-formatted.crt'
db configuration setprop pki KeyFile '/path/to/private/pem-formatted.key'
signal-event certificate-update

The issue with Chrome 58 was gone.
I can switch between secure and unsecure by switching the certificates.

1 Like

By modifying the /etc/pki/tls/openssl.cnf file, one would be able to create the necessary certificate using the Neth Gui.

So the solution is just adding that info to our certificate? Is it quickly doable @giacomo ?

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.

Am I missing something?
/cc @flatspin @islipfd19

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.

1 Like

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.

1 Like