search

debops / ansible-pki

Bootstrap and manage internal PKI, Certificate Authorities and OpenSSL/GnuTLS certificates
GNU General Public License v3.0
65 stars 29 forks source link

CA hardening and status URI change support #105

Closed ypid closed 7 years ago

ypid commented 7 years ago

Not sure yet if item.domain is a sensible name constraint default. Certainly restrictive but for most of my usecases, this works. Some feedback on this would be required before merging.

Closes: https://github.com/debops/ansible-pki/issues/87

ypid commented 7 years ago

There's also this analysis which concludes that the nameConstraints field doesn't really matter at all.

That seems to be from 2012. Mozilla has the Web PKI x509 certificate primer recommending its use last updated 2015. This is not a too commonly used extension but it’s support should be mature and it is recommended to set it to critical which I did now. https://www.sysadmins.lv/blog-en/x509-name-constraints-certificate-extension-all-you-should-know.aspx

Yup, tested it, refer to the commit message: https://github.com/debops/ansible-pki/pull/105/commits/cb8ed64eab6fcf81c35590156df35fecf844add3

And it only is supposed to matter during certificate verification and not signing?

I have not researched how this is handled by OpenSSL further. My understanding is that it is mainly checked during certificate verification by clients but I also get "lookup:permitted subtree violation" errors on Ansible runs where I issued certs which are outside of nameConstraints for testing. So, it appears debops.pki might still issue such certs, but that is not really relevant here. The extesion is set to critical so it MUST be checked during cert verification. It could be enforced during singing as well of course (or checked if openssl can do this) but that is not really necessary (in contrast to https://github.com/debops/ansible-pki/issues/106).

drybjed commented 7 years ago

Just as a follow up, this article has a paragraph:

If a client encounters something in a certificate that is marked critical, but the client does not know how to understand what it is seeing, then the client must drop the connection with an error. If a client encounters The HARICA’s CA, but the client does not understand the Name Constraints section, that’s OK with the client, because that section is not marked critical.

Since by default, debops.pki will add nameConstratints as critical, I wonder how many clients might not work properly... Although the article is from 2014, so things might have changed in the meantime. Perhaps dropping the critical status by default and making it optional could be benefical as making the role and its environment easier to use for new users? @ypid, what do you think?

ypid commented 7 years ago

I changed it to critical as I think that is the proper default. I also found reports/issues from years ago and but as it’s seems to be recommended to set critical for it now I went with it. I would just see if something actually breaks. And I guess if it does, the client software might not be up-to-date (so it should be updated).

Thanks for merging.

drybjed commented 7 years ago

OK, let's leave it as is then, for now.