3:19 p.m.
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(a)redhat.com> wrote:
Hi Sergiio,
Am Mi., 8. Apr. 2020 um 18:53 Uhr schrieb Sergio Oliveira Campos
<seocam(a)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-s...
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...
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
--
Sergio Oliveira Campos
Senior Software Engineer, Identity Management (IdM)
Red Hat <https://www.redhat.com>
<https://www.redhat.com>