Chrome 58 doesn't work with nethserver

Support
,
#1

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.

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.

Anyone else whose having this problem?? :disappointed_relieved:

1 Like
SubjectAltName for Certificates
#2

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
#3

Hi Gabriel, thanks for reply.

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

#4

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.

1 Like
#5

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

It works fine.

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

#6

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

#7

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

#8

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
#9

@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?

#10

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”

#11

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.

image.png789×94 5.23 KB

4 Likes
#12

Appendix:

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
#13

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

http://community.nethserver.org/t/subjectaltname-for-certificates/6786/2

#14

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

#15

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.

#16

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

#17

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
#18

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