You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This complicates things in terms of identifying certificates. Currently txacme identifies certificates by "server name", which is currently (although doesn't have to be), the common name (CN). Once there is SAN support, a certificate can be uniquely identified by all its domains CN + SAN (although I'm not sure if the order of those domains matters). So, on the surface, identifying a cert by its SANs seems reasonable. The problem is once you want to change the SANs in a cert, then you have a new list of domains and can't identify the old cert.
The first two ways I can think of to solve this are:
Identify certificates by CN. This then means that multiple certificates are not allowed with the same CN.
Use some other user-specified identifier for the certificate. Something like Certbot's --cert-name option (see Managing Certificates).
The text was updated successfully, but these errors were encountered:
This is mostly dependent on SAN support (#37).
We would like to be able to:
See the Certbot documentation on re-creating and updating existing certificates.
This complicates things in terms of identifying certificates. Currently txacme identifies certificates by "server name", which is currently (although doesn't have to be), the common name (CN). Once there is SAN support, a certificate can be uniquely identified by all its domains CN + SAN (although I'm not sure if the order of those domains matters). So, on the surface, identifying a cert by its SANs seems reasonable. The problem is once you want to change the SANs in a cert, then you have a new list of domains and can't identify the old cert.
The first two ways I can think of to solve this are:
--cert-name
option (see Managing Certificates).The text was updated successfully, but these errors were encountered: