Conversation

Notices

1. Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 06:35:43 JST Aral Balkan

   How very bizarre… Chrom(ium) chokes if your TLS server certificate has an @ symbol in the Common Name (CN) field. It also fails with an “unable to parse file” error if you try to import a certificate authority that has the same (but, if you add the same certificate authority to the system trust store, it imports it without issue when you next start the browser).

   TL; DR: Do not use the @ symbol in the Common Name (CN) fields of your TLS certificates.

   #chrome #chromium #bug #tls #ssl #pki

   • Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 06:37:44 JST Aral Balkan

     in reply to

     (Firefox has no trouble with the same certificates and neither does OpenSSL.)

   • Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 06:55:03 JST Aral Balkan

     in reply to

     • Paul Sutton

     @zleap I don’t really see how this could have a security implication. It’s more an issue with dense/hard to read RFCs. For such fields, it also looks like some certificate authorities have their own limits, etc., so I’m not sure how standardised some of those are. Best to keep them simple, I guess.

   • Paul Sutton (zleap@qoto.org)'s status on Saturday, 07-Jan-2023 06:55:04 JST Paul Sutton

     in reply to

     @aral

     I am not a security expert but when I look at things like this, then read about security issues at Lastpass and other companies, is there a link. Surely the industry needs to get it's act together ASAP over all this.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 06:57:26 JST Aral Balkan

     in reply to

     • Paul Sutton
     • Gabriel Schneider

     @gbrls It’s not :)

     @zleap

   • Gabriel Schneider (gbrls@infosec.exchange)'s status on Saturday, 07-Jan-2023 06:57:34 JST Gabriel Schneider

     in reply to

     • Paul Sutton

     @zleap @aral how's this related to the lastpass incident?

   • Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 07:00:39 JST Aral Balkan

     in reply to

     • Elliot Schlegelmilch

     @elliot If you have Subject Alternate Names, the CN should be ignored. But yes, you’re right, in normal usage it wouldn’t make sense.

     (This is for local development certificates so I was getting fancy. Lesson learned: don’t get fancy.)

     (That said, it accepts spaces, so…) ¯\_(ツ)_/¯

   • Elliot Schlegelmilch (elliot@microscopic.network)'s status on Saturday, 07-Jan-2023 07:00:40 JST Elliot Schlegelmilch

     in reply to

     @aral I know that you can make a cert with nearly anything in any field but a cn with something other than a domain name would not validate in a browser, would it?

     or am I misremembering something about tls?

   • Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 07:03:28 JST Aral Balkan

     in reply to

     • Elliot Schlegelmilch

     @elliot So Chrom(ium) is fine with, for example:

     Common Name (CN): Localhost certificate for aral at dev.ar.al

     but chokes if that reads:

     Common Name (CN): Localhost certificate for aral@dev.ar.al

   • Aral Balkan (aral@mastodon.ar.al)'s status on Saturday, 07-Jan-2023 21:26:16 JST Aral Balkan

     in reply to

     • null

     @0 Ah, thanks, I hadn’t seen that.

     (And, yes, especially if so.)

   • null (https://f.cz/@0)'s status on Saturday, 07-Jan-2023 21:26:17 JST null

     in reply to

     @aral especially considering chrome does not actually care about CN at all and only matches valid identity on SAN https://developer.chrome.com/blog/chrome-58-deprecations/#remove-support-for-commonname-matching-in-certificates