Warning on Chrome 58

[john9527]

One thing I'm not 100% satisfied with is I'm duplicating sections to add the new parameters. Openssl doesn't seem to mind and merges parameters from both duplicatas. To make this cleaner would require some sed magic to insert the parameters in the temporary openssl.config file.

I was using your helper.sh.....and operating on the openssl.config. Made it easy to play with things by modifying gencert.sh

You need to change the openssl config file to tell it to copy extensions when signing the certificate (for security reasons, extensions are not copied by default, as if you were signing someone else's CSR, you might end up leaking confidential info when copying extensions from your CA...).

I had made this change as well, but still can't get the v3 extensions. I'll look at your changed commands.

 

[sfx2000]

FWIW - Chrome 58 is behaving just plain weird... at least in the version I have at the moment...

Version 58.0.3029.81 (64-bit)

It's having issues with QNAP as well - didn't happen with 57-stable..

 

[john9527]

FWIW - Chrome 58 is behaving just plain weird... at least in the version I have at the moment...

I suspect it's going to break nearly everyone that uses a self-signed cert....implementing a 17 year old RFC, where a different 'convention' has already been established. Shaking my head.

There's another change I ran across that requires MIME types to be specified where they weren't required before....see a breakage in streaming servers coming.

 

[john9527]

@RMerlin - Thanks for the new commands.....did the trick

One upside I can speculate on....this may resolve the problems of using IP address vs DNS names to access the router.

 

[RMerlin]

I just committed an updated version, this one uses sed to properly insert the new attributes in the correct locations.

 

[RMerlin]

Thanks for the new commands.....did the trick

One thing that's not really documented is you cannot provide config parameters for the openssl x509 command, for some reason (must be why "-config" is invalid when using the x509 command). Relying on the req command instead does work. Took me a while to figure out that one as well.

 

[john9527]

I made two additional changes.....(I'm sure you know where they go )

First added

echo "$I.organizationName=O" >> /etc/openssl.config
echo "$I.organizationName_value=$(uname -o)" >> /etc/openssl.config

This makes the certification list a little more readable....

Next....a bug workaround (first DNS entry)

echo "DNS.$I = $LANIP" >> /etc/openssl.config    # workaround for IE not supporting IP SAN

EDIT: One more thing....Chrome was complaining about the Secure Connection status with the key size of 2048. It was happier when set to 1024. Go figure.

 

[RMerlin]

First added

Probably a good idea. I'm not really satisfied with the very limited amount of data filled in the certificate, we should probably fill up the rest as well. Just need to figure out what to put there. For a while, I even considered retrieving the country from the router's wifi region, but decided against it since "EU" is probably not a valid country

Next....a bug workaround (first DNS entry)

I'd like to see an RFC first to determine if using an IP in a DNS entry is valid or not. Wouldn't want to break other clients just for that one client that's no longer even developed by Microsoft (even tho I think it's replacement, Edge, is currently garbage).

EDIT: One more thing....Chrome was complaining about the Secure Connection status with the key size of 2048. It was happier when set to 1024. Go figure.

The only complain I'm getting here is about the fact the root CA isn't recognized. Got a capture of the actual warning you get on this?

1024-bit is out of the question, it's no longer considered secure. I upgraded to 2048-bit a few years ago because of this.

 

[john9527]

I'd like to see an RFC first to determine if using an IP in a DNS entry is valid or not. Wouldn't want to break other clients just for that one client that's no longer even developed by Microsoft (even tho I think it's replacement, Edge, is currently garbage).

No problems I've found with FF or Chrome....and I verified the behavior on IE and that it is fixed. From what I found, all it is is a string match on the DNS name, so should do no harm. I still need IE/Win7, so am going to include it. BTW, I've found that they have actually been fixing some things in IE in some of the latest windows updates even though they say that dev has stopped. On a side note, I've seen the latest FF releases go runaway with memory use if you leave it up for a long time in the background.....grabbing up to 1GB of memory

The only complain I'm getting here is about the fact the root CA isn't recognized. Got a capture of the actual warning you get on this?

Seems it only shows up on the initial screen when it blocks the access and goes away once the cert is loaded. Why is shows this way for the larger key only is the mystery. Here's the message....
Obsolete Connection Settings
The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a strong cipher (AES_128_GCM).

 

[RMerlin]

The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a strong cipher (AES_128_GCM).

Looks like the warning is about the key exchange mechanism (RSA) rather than the bit strength. Odd, since I did implement ECDHE support, and it's properly used here when I access to my router:

Can you check that your mssl code is in sync with mine? Especially this commit:

commit f6b875f2bbf330fe40bcb55031a6ccd0a2cad3be
Author: Eric Sauvageau <rmerl@lostrealm.ca>
Date:   Sun Mar 22 02:52:55 2015 -0400

    mssl: Remove obsolete ciphers such as RC4, and add support for ECDHE

 

[RMerlin]

Found the matching RFC: https://tools.ietf.org/html/rfc3280#section-4.2.1.7

Based on this, I'd say that defining an IP address with both an IP and a DNS label might be fine, and would cover all scenarios. Just need to make sure that the duplicate doesn't cause any issue.

 

[john9527]

Can you check that your mssl code is in sync with mine? Especially this commit:

Yep....picked that up back in 2015 when you had originally committed it. I stay pretty well up to date on any security related changes you make.

But....I went back again to recreate it, and I no longer can
At this point I'm going to chalk it up to something left hanging in cache when I was playing around creating certs to try and get the v3 extensions working.

 

[RMerlin]

I sent the new gencert.sh script upstream to Asus, hopefully they will implement at least the SAN support on their end.

 

[MichaelCG]

This fun hit us on the enterprise side this past week. Luckily for us we had already been talking about it for a couple of weeks so as soon as the calls started rolling in, our client ops guys pushed an update to the Enterprise Chrome policy to disable this (SAN) check for now.

I hate how Google approaches some of the change...but hey, someone has to do it or we end up with an absolute mess over the years since nobody wants to "break" anything. As long as Google is actually enforcing the RFC and not their own proprietary things, I can get on board.