Hello everyone,
I'm working on an Ansible Linux System Role to issue and renew certificates. The first version of this role will use Certmonger but later other providers will probably be implemented. Initially the supported CAs will be IPA and local (self-signed).
The proposal for the API is currently here: https://github.com/seocam/certificate If you have time to take a look and provide some feedback that would be great.
I'm on IRC if you want to chat about it (seocam @ Freenode).
Thank you!
Hi Sergiio,
Am Mi., 8. Apr. 2020 um 18:53 Uhr schrieb Sergio Oliveira Campos seocam@redhat.com: Hello everyone,
I'm working on an Ansible Linux System Role to issue and renew certificates. The first version of this role will use Certmonger but later other providers will probably be implemented. Initially the supported CAs will be IPA and local (self-signed).
The proposal for the API is currently here: https://github.com/seocam/certificate
the key_size defaults to 2048 bit which seems to be a bit low nowadays, NSA and Ecrypt recommend at least 3072 nowadays: https://www.keylength.com/en/compare/
IMHO the role should also specify that it will increase the default value in the future to adjust to best practices. Another idea would be to actually use a security level (legacy, default, future) that would also adjust the hash algorithm (which seems to be missing from the options).
Fields like country, state, locality do not seem to make sense nowadays. Therefore it might make sense to only add them if there is actual demand for them to keep things simpler. It also does not seem worth to be mentioned in an example.
Also the common_name is deprecated and AFAIK browers like chrome require a DNS subject alternative name. So fior example https://github.com/seocam/certificate#certificates-with-one-or-more-san-subj... is a bad example since the common name should also be included in the DNS alternative names. See for example https://stackoverflow.com/questions/43665243/invalid-self-signed-ssl-cert-su...
Stopping a web server (run_before) before signing the certificate seems to be odd. I am sure (and hope) that webservers will only load the crypto files at startup, so only after updating the certificate, the service should be reloaded or restarted (depending on what is necessary to make it load the new crypto files). Also the role should make sure that it will no overwrite the old files with invalid data in case of an error and only update the on-disk files on success. Also for the run_after command, it might be useful to support place-holders or environment variables about the certificate location or whatever could be useful.
Also I guess it would be nice to also support letsencrypt as a CA.
Hope this helps Till
@Sergio: Resent this to include the mailing list.
Hi Till,
I'll have to verify if we don't have any need for the fields you suggested we remove. If we don't need it, I'll take them out I'll also update the examples to ensure we are following the up-to-date best practices.
A stronger default key size seems good to me and documenting that default algorithms and key size might change in future, in order to match new recommendations, sounds really needed.
As odd as "run_before" seems, we do have a few specific cases where we actually need it. That's in our MVP requirements.
Thanks for the feedback!
On Wed, Apr 8, 2020 at 4:23 PM Till Maas till@redhat.com wrote:
Hi Sergiio,
Am Mi., 8. Apr. 2020 um 18:53 Uhr schrieb Sergio Oliveira Campos seocam@redhat.com: Hello everyone,
I'm working on an Ansible Linux System Role to issue and renew certificates. The first version of this role will use Certmonger but later other providers will probably be implemented. Initially the supported CAs will be IPA and local (self-signed).
The proposal for the API is currently here: https://github.com/seocam/certificate
the key_size defaults to 2048 bit which seems to be a bit low nowadays, NSA and Ecrypt recommend at least 3072 nowadays: https://www.keylength.com/en/compare/
IMHO the role should also specify that it will increase the default value in the future to adjust to best practices. Another idea would be to actually use a security level (legacy, default, future) that would also adjust the hash algorithm (which seems to be missing from the options).
Fields like country, state, locality do not seem to make sense nowadays. Therefore it might make sense to only add them if there is actual demand for them to keep things simpler. It also does not seem worth to be mentioned in an example.
Also the common_name is deprecated and AFAIK browers like chrome require a DNS subject alternative name. So fior example
https://github.com/seocam/certificate#certificates-with-one-or-more-san-subj... is a bad example since the common name should also be included in the DNS alternative names. See for example
https://stackoverflow.com/questions/43665243/invalid-self-signed-ssl-cert-su...
Stopping a web server (run_before) before signing the certificate seems to be odd. I am sure (and hope) that webservers will only load the crypto files at startup, so only after updating the certificate, the service should be reloaded or restarted (depending on what is necessary to make it load the new crypto files). Also the role should make sure that it will no overwrite the old files with invalid data in case of an error and only update the on-disk files on success. Also for the run_after command, it might be useful to support place-holders or environment variables about the certificate location or whatever could be useful.
Also I guess it would be nice to also support letsencrypt as a CA.
Hope this helps Till
@Sergio: Resent this to include the mailing list.
-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
systemroles@lists.fedorahosted.org