Skip to content
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

No subjectAltName in Icinga CA created CSRs #5194

Closed
chrkli193 opened this issue Apr 26, 2017 · 5 comments · Fixed by #5246
Closed

No subjectAltName in Icinga CA created CSRs #5194

chrkli193 opened this issue Apr 26, 2017 · 5 comments · Fixed by #5246
Assignees
Labels
area/api REST API area/cli Command line helpers bug Something isn't working
Milestone

Comments

@chrkli193
Copy link

Hello,

if I create a new CSR with

icinga2 pki new-cert --cn "hostname.test.de" --key "testhost.key" --csr "testhost.csr"

and have a look in the created CSR I don't see that subjectAltName is filled with the cn.

I expect something like this in the CSR:
X509v3 Subject Alternative Name:
DNS:hostname.test.de

I found some code (line 509) in
https://github.com/Icinga/icinga2/blob/master/lib/base/tlsutility.cpp
which I think should add the SAN to the certificate but it's not.

I found also an issue which is already closed:
#4103

I tried that with Icinga 2.6.3 on CentOS7 and also on Ubuntu 16.04.
Also setting up a complete new environment doesn't create the SAN.

Maybe I did something wrong or there is a missing switch but I cannot add the SAN.

Greetings

Christoph

@gunnarbeutner gunnarbeutner added area/api REST API bug Something isn't working area/cli Command line helpers labels Apr 27, 2017
@dnsmichi
Copy link
Contributor

For reference: https://mta.openssl.org/pipermail/openssl-users/2016-January/002764.html - seems openssl itself doesn't use that info from CSRs itself too.

If you want to come up with a fix:

  • store the SAN inside the CSR in new-cert cli command
  • read the SAN from CSR in the sign-csr cli command and add it to the generated certificate

@gunnarbeutner
Copy link
Contributor

Looks like we're not currently setting SANs for CSRs. Out of curiosity, what's your use case for this?

@chrkli193
Copy link
Author

The last Chrome update marks all certificates red (unsecure) which do not have the SAN set. We are using the Chrome Multi Status Plugin which queries the api and that certificate does not have set the SAN. That's the reason.

@lazyfrosch
Copy link
Contributor

lazyfrosch commented Apr 27, 2017

I noticed that issue with an internal site in the last days.

Chromium warns about "Subject Alternative Name Missing"

Reference: https://bugs.chromium.org/p/chromium/issues/detail?id=308330

The explanation is rather interesting:

RFC 2818 discouraged the practice > 10 years ago, as it was only intended for legacy. The Baseline Requirements require a subjectAltName, and require that the only host-ish names in a CN must be a name also in the SAN.

@dnsmichi
Copy link
Contributor

Understood, thanks for the details.

@gunnarbeutner gunnarbeutner changed the title No subjectAltName in Icinga CA created certificates No subjectAltName in Icinga CA created CSRs May 11, 2017
@gunnarbeutner gunnarbeutner self-assigned this May 11, 2017
gunnarbeutner added a commit that referenced this issue May 11, 2017
Add subjectAltName X509 ext for certificate requests

fixes #5194
fixes #5246
@gunnarbeutner gunnarbeutner added this to the 2.7.0 milestone May 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api REST API area/cli Command line helpers bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants