[enh] Variabilize the certification authority

[SveDec]

The problem

YunoHost/issues#2552

Solution

This PR variabilizes the certification authority. This first step will allow a simple modification to choose an alternative certification authority.

PR Status

Work in progress

TODO

• Add settings for the cert auth
• Use the new settings instead of hardcoded values
  • Use the CA's ACME URL setting in the certificate part's source code
  • Change the variables' name containing LE/letsencrypt for a more generic one
  • Use the CA's name setting instead of letsencrypt/Let's Encrypt
    -> don't forget translations
• Adapt the code to other CA
  • Add at least the domain to the SAN list in the CSR
  • Adapt parts of the code that are specific to LE
  • Anything else ?
• Handle a CA change with existing certs
  -> to be discussed : shall we try to renew certs issued by an old CA with the old CA, or delete them and request new certs to the new CA ?
• Tests IRL

How to test

• Request and renew certs with the default settings -> should have the exact same behavior as before
• Request and renew certs with another CA -> should work the same way

[zamentur]

This var is only used one time line 540, we probably should call this function only when we really need it.

[zamentur]

So here it's a global settings and not a domain settings.

I imagine it's the good solution to choose a global settings for that

[SveDec]

The function is now called only once, and the settings put into variables.

[zamentur]

Maybe we should do something with this

[SveDec]

Variabilized. We'll have to verify how different CA write their name in their certificates.

[zamentur]

Same here

[SveDec]

Variabilized.

[zamentur]

I guess this should be adapted too

[SveDec]

Variabilized. Later we may want to move the file into another directory (e.g. /etc/yunohost/cert/*something*/) but it is a breaking change that needs to be handled.

[zamentur]

• In the actionmap we have a --install-letsencrypt-cert option, i guess we should create an option like --install-tls-cert or --install-x509-cert or --install-certificate and mark the old option as deprecated in the action map)
• About CAA, i guess allowing to change CA could triggers error when CAA DNS record is not matching the CA choosen in settings. Do we should check that point before doing the Certificate request ? Or we wait the CA to refuse to sign the certificate ?

[frju365]

I don't know if it's the good place to speak about this, but I did some test, and acme client used by Yunohost is mostlly used for LE certificate and is not really good for other CA (for example CA who uses ACME AUTH). The best would be to use certbot-python... but it will imply a lot of changes.

[frju365]

Previous comment : only concerns alternative CA who handles ACME certs.

[SveDec]

I think I replaced "Let's Encrypt"/"letsencrypt" everywhere it was needed, except in the --install-letsencrypt-cert option (I leave this change to @zamentur who raised this point).
Note that I sometimes used a generic term like "the certification authority" instead of the appropriate setting (certification_authority_fullname) because I did not understand how to include a variable in some strings ...

[SveDec]

To handle the CA change, how about saving the CA settings used to generate a certificate along with it, in it's own /etc/yunohost/certs directory ? With a little bit more logic in different parts of the code, I think it could allow :

• to keep renew a cert with the original CA, even after a CA change in the settings,
• to replace a cert issued by the "old" CA with a new one issued by the "new" CA,
• to handle conflicts between the CAA record and the CA of a cert (and force a renewal with the good CA for instance) ...

Feedback welcomed on this point.