Certificates on failover server / listing certificates with methods


#1

Thanks for the reply and the link.

On our server that does not work, since some of the certificates are for fail-over use (after changing DNS records). So, we could only verify those certificates by DNS or HTTP by switching real operations to the failover server. Will not do that until it is really needed (hopefully never).

Surely there must be a “letsencrypt” or “certbot” command to list all certificates with their validation methods, or instructions where to find some configuraiton file. This is completely missing in the step-by-step instructions for how to deal with the “TLS” method no longer going to be supported. Are we somehow using the “TLS” method or not?


TLS-SNI-01 validation is reaching end-of-life
#2

Yes there are:
certbot certificates
letsencrypt certifictes
Both will show the certs issued, the names they cover, and the cert expiration date [and also shows it as XX days - for ease of use].


#3

Hi @joheben! I moved this post to a new topic so it doesn’t get mixed up with the previous one.

@rg305 is right, you can list your certificates that way, but I’m afraid it doesn’t list the validation methods used.

Have you read How to stop using TLS-SNI-01 with Certbot yet? The main thing you need to do is check that your Certbot is up-to-date (at least 0.28.0). If it is, there’s a 99% chance you’re fine. The only way you might not be fine is if you passed a special flag to choose TLS-SNI, or if you have an unusual firewall config.

Out of curiosity, how did you issue certificates on your failover server previously?


#4

Apologies for slow responding. Thanks for replying and moving to a separate topic.

The upgrade instructions (for 0.28) did not work, I had to use a forcing method telling letsencypt/certbot to upgrade even though it did not want to (found working instructions by another user) .

I did carefully read the page How to stop using TLS-SNI-01 with Certbot
It assumes that the reader has detailed knowledge about the inner workings of certbot. For example, the reader is assumed to know where to find “your renewal configuration”. In our system it was not in any known location (I could not find it).

I have no idea if some special flag was passed to choose TLS-SNI-01 (a previous employee made the installation). I also have no information on how SSL certificates were issued previously, but it was a more manual method.

Isn’t it odd that there is no tool or documentation for finding out what validation methods are in use?

It looks as if we will find out only when we are really in a hurry to make our failover server fully operational. Not ideal.


#5

Sorry this has been a confusing process for you. I can tell you this: If your failover server is not serving active traffic, it has not been getting up-to-date certificates via TLS-SNI-01. If you want to make sure your failover server always has an up-to-date certificate, you will need to do some engineering work regardless of the TLS-SNI-01 deprecation.

A couple of ways that could work:

  • Your failover server could regularly copy the current certificate from your main server, and reload Nginx or Apache so that certificate becomes active.
  • You could have a third server issuing via DNS-01, and pushing out the resulting certificates to both the failover server and the main server, and reloading Nginx or Apache.

It sounds like your goal is to minimize the effort associated with installing certificates, which is quite understandable, so I’m guessing these approaches won’t work for you. And it does sound like you’re aware that there’s a risk that your failover server won’t work when you most need it to. Note that this was almost certainly true before the TLS-SNI-01 deprecation as well.


#6

I do agree that our setup is a little odd, relying mainly on avoiding the need for using the failover server at all. Redundancy-copying all critical data from the active server (including certificates) does seem the wisest path to follow.

We will be overhauling our entire deployment structure soon. For now, certbot is workable for quickly (but not ensured) getting the failover server up and running “with no great delay”, but we can for sure do better.

Thanks for your patience and help.


#7

If you don’t mind me adding my two cents…
[and sorry about the long read - in advance - I did try to shrink it]

We often test fire systems and emergency generators for obvious reasons = they must work when they are most needed (in an actual emergency).
In my mind, this should be treated no different; Your backup system should work whenever needed.
If you have a standby/backup system and only use it when you absolutely need it - how can you ever be sure it will work? That it is even ready to work? Does the spare tire still have enough air in it?

Regular testing, or a scheduled role rotation, could ensure that multiple systems are fairly up-to-date and are indeed working as expected.
[presuming each are of similar size and capacity, where any single system can handle the full load - I would just rotate them every couple of weeks]


closed #8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.