Issues requesting a duplicate cert for secondary web server

Please fill out the fields below so we can help you better.

My domain is: almacenetworks.com

I ran this command: sudo certbot --apache --duplicate -d www.almacenetworks.com

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for www.almacenetworks.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.almacenetworks.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested ad0e2c7e64566b0a0625cfda1dbfb4ff.3bbdd07e0cf67a7bbd03cc4a2db4f6e9.acme.invalid from 107.170.29.197:443. Received 2 certificate(s), first certificate had names “www.almacenetworks.com

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.almacenetworks.com
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    ad0e2c7e64566b0a0625cfda1dbfb4ff.3bbdd07e0cf67a7bbd03cc4a2db4f6e9.acme.invalid
    from 107.170.29.197:443. Received 2 certificate(s), first
    certificate had names “www.almacenetworks.com

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address.
    #Note - there is already an A record for this server

My web server is (include version): Apache httpd-2.4.6-45.el7.centos.4.x86_64

The operating system my web server runs on is (include version): Centos 7

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

Just to clarify, I’m looking to request another www. cert for a secondary web server. I am looking to do a high availability configuration with multiple web servers.

Hi @nedwards,

How did you obtain and install your original certificate?

I agree that the error message you encountered is a problem (which might also indicate an upcoming problem with renewal), but if you’re going to copy the certificate onto the other server, why not copy the original certificate and private key directly? Neither browsers nor CAs nor web servers have any objection to having multiple machines literally use exactly the same certificate and key.

There are some cases in which it produces a slight reduction in security in some threat models but I speculate that that’s not a very significant concern here.

Thanks for replying. I obtained and installed my initial cert via certbot on my primary web server. It was a while back, but I think I simply used this command:

sudo certbot --apache -d www.almacenetworks.com

Renewals work with no issues on that server.

If possible, I’d ultimately like to have certbot manage the issuance and renewal for both boxes. I’m not super familiar with how the verification process works, but there shouldn’t be an issue getting two certs for the same domain as long as the serial numbers are different.

Oh, are you running this --duplicate command on the other server right now?

No. I’m only running the --duplicate when I try to request a cert for the secondary server.

So I have to admit that I don’t understand why the renewal works but the --duplicate doesn’t, since they’re actually doing exactly the same thing under the hood! (The apache plugin itself doesn’t know at all whether the new issuance that it’s causing is related to an existing certificate or not.) How recently have you renewed with certbot renew?

I run the renewal process twice a day on the primary server, but the cert was last actually renewed on 6/30/2017.

None of this is in play on the secondary server as I’ve not gotten a cert successfully issued.

As a follow-up, I see that you have two IP addresses, 104.131.143.236 and 107.170.29.197. Maybe one of these is the primary server and the other is the secondary server?

The former is serving a self-signed certificate for “AlmaceWeb2”, while the latter is serving your existing Let’s Encrypt certificate. But you’re saying that the failed certbot --apache command is running on the primary, not the secondary, server? The error message that you saw would certainly be explained by running your Certbot on the secondary server (104.131.143.236).

Correct, my secondary is 104.131.143.236. Here’s the renewal output from 107.170.29.197 from just now:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/www.almacenetworks.com.conf

Cert not yet due for renewal

The following certs are not due for renewal yet:
/etc/letsencrypt/live/www.almacenetworks.com/fullchain.pem (skipped)
No renewals were attempted.

So, the ACME protocol doesn’t have a way to say “Please check my IP address”, and the Let’s Encrypt CA also doesn’t say “I’ll check the IP address that you’re connecting from”. Instead, it chooses a random IP address from the resolved IP addresses and tries to connect to that one. That means that if you have a DNS name that resolves to several different IP addresses, you generally can’t use the TLS-SNI-01 challenge method (which is used by --apache) because you can’t make one server reconfigure all of the other servers’ TLS listeners, and you often can’t use the HTTP-01 method (which is used by --webroot) if the webroots of the various servers aren’t all served from the same underlying data store or filesystem or rapidly synchronized.

The recommended way to get certificates from Let’s Encrypt in this configuration is either:

  • HTTP 301 redirect /.well-known/acme-challenge from the HTTP listeners on all machines to one central machine, and do all of the issuance on that machine (using HTTP-01 method, so typically --webroot with Certbot), or
  • Use the DNS-01 authentication method, which involves updating the DNS zone with a specified TXT record to prove control (typically --manual --preferred-challenges dns-01 with Certbot, or use acme.sh instead of Certbot for wider DNS provider API support)

If this doesn’t make sense, I can expand upon it a little bit.

Interesting. I’ll give the DNS-01 method a shot. Thanks for your help.

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