Certificate Role - Design Proposal

[Sergio Oliveira Campos]

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!
-- 

Sergio Oliveira Campos

Senior Software Engineer, Identity Management (IdM)

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

[Till Maas]

Hi Sergiio,

Am Mi., 8. Apr. 2020 um 18:53 Uhr schrieb Sergio Oliveira Campos
<seocam(a)redhat.com&gt;:
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]

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&gt; wrote:

>  Hi Sergiio,
>
>  Am Mi., 8. Apr. 2020 um 18:53 Uhr schrieb Sergio Oliveira Campos
>  <seocam(a)redhat.com&gt;:
>  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>