I think that this allows us to piece together an explanation of what you’re experiencing.
Around the beginning of this year a security problem was found with the TLS-SNI-01 validation method (which uses port 443). This has to do with certain large shared hosting providers’ configurations and might allow one user of a hosting provider to inappropriately obtain a certificate for a different user, in some circumstances.
Because of this, the use of this method was restricted by Let’s Encrypt:
TLS-SNI can be used for revalidating and reissuing certificates for domain names that have previously-issued Let’s Encrypt certificates. This is limited to the account that issued the most recent certificate for any given domain name. It applies whether or not the certificate used TLS-SNI for validation. It applies only to fully-qualified domain names, not subdomains.
Since you have a new server, you presumably have a new Let’s Encrypt account (the account is automatically generated the first time you use a Let’s Encrypt client on a particular machine). That new account isn’t eligible to use TLS-SNI-01 validation on port 443 because it isn’t the most recent account that issued a certificate for your domain.
Your options are:
- Find the account file in
/etc/letsencrypt/accounts on the old machine and install it on the new server (removing the account that was automatically created on the new server)
- Permanently unblock port 80
Temporarily unblock port 80 and issue a certificate, then re-block it (because then the account would be the most recent account to have issued a certificate for that name) (per @jsha’s observation below, this method is not suggested because it may make your renewals fail again at some point in the future)
- Temporarily or permanently use the DNS-01 challenge method instead to issue your certificate)
-a webroot always uses exclusively port 80, not port 443. This has always been true for the whole history of the project. If port 80 has always been blocked on your server, you were presumably previously using
-a nginx, or
-a standalone, which could have used TLS-SNI-01 on port 443.