The order of wildcard DNS SAN entries matters
Categories
(Firefox :: Security, defect)
Tracking
()
People
(Reporter: anacrolix, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Steps to reproduce:
I issued a certificate with several wildcard SAN entries. Let's say *.b.a, and *.a. I then visit c.b.a. If the certificate has the entries in the order *.a, then *.b.a, I get SSL_ERROR_BAD_CERT_DOMAIN. If I change the certificate to *.b.a, then *.a, it's fine.
Note that I tested various combinations, including having *.b.a in the CN for the cert. Chrome and curl (with openssl) do not seem to take issue. My stack uses Go, I suspect it doesn't have an issue either, but I haven't tested it as a client in this set up.
I do not think this is a security issue in the sense that users could be harmed. Firefox will just show warnings about pages being insecure when they probably aren't. Maybe if they added an exception for that and something later changed, it could be a security issue.
Actual results:
SSL_ERROR_BAD_CERT_DOMAIN
Expected results:
No error.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Security' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Hi anacrolix,
Can you try to reproduce this issue on the latest nightly build?
I see that the product and component for this ticket is set. Let's wait for the corresponding team's feedback. In the meantime please feel free to add any other info you can provide in order to help investigate.
Thanks,
Estanislao
Wildcards like *.example aren't supported, so if one is encountered before a valid wildcard, it'll be rejected. It's probably best to avoid this.
Description
•