-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for duplicate SANs in signed certificates #16700
Conversation
981fa2f
to
5dce854
Compare
\o Hey @rubendv, thanks for the PR! :-) Do you mind adding a test for this? It'd be great to make sure we don't break this again in the future. |
Sure! I will look into it. |
I added tests @cipherboy. I noticed in the contributing guide it says that PRs should reference issues, would you like me to still create an issue for this PR? |
@rubendv Nah, no point IMO. I understand the problem well enough. Thank you! |
@rubendv Actually, could I bother you to rebase this on top of a newer Looks like rerunning it didn't help:
|
…sent in the CSR SAN extension and UseCSRValues is true. When UseCSRValues is true (as is the case on the sign-verbatim endpoint), all extensions including Subject Alternative Names are copied from the CSR to the final certificate. If the Subject Alternative Name in question contains any othernames (such as a Microsoft UPN) the SAN extension is added again as a workaround for an encoding issue (in function HandleOtherSANs). Having duplicate x509v3 extensions is invalid and is rejected by openssl on Ubuntu 20.04, and also by Go since golang/go#50988 (including in Go 1.19). In this fix I do not add the extension from the CSR if it will be added during HandleOtherSANs.
a752311
to
e56cfad
Compare
Thanks @rubendv, that worked! |
When UseCSRValues is true (as is the case on the sign-verbatim endpoint), all extensions including Subject Alternative Names are copied from the CSR to the final certificate.
If the Subject Alternative Name in question contains any othernames (such as a Microsoft UPN) the SAN extension is added again a few lines later as a workaround for an encoding issue (by function HandleOtherSANs).
This way you end up with two copies of the SAN extension in the final certificate.
Having duplicate x509v3 extensions is invalid and is rejected by openssl on Ubuntu 20.04 (but not on Ubuntu 18.04), and is also rejected by Go in x509.ParseCertificate since golang/go#50988 (part of Go 1.19).
In this fix I do not copy the extension from the CSR if it will already be added by HandleOtherSANs.