# Issues requesting a duplicate cert for secondary web server

**URL:** <https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382>\
**Category:** Help\
**Created:** [August 2, 2017, 2:17pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382 "2017-08-02T14:17:23Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 2:17pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/1 "2017-08-02T14:17:23Z")

</div>

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

My domain is: [almacenetworks.com](http://almacenetworks.com)

I ran this command: sudo certbot --apache --duplicate -d [www.almacenetworks.com](http://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](http://acme-v01.api.letsencrypt.org)  
Obtaining a new certificate  
Performing the following challenges:  
tls-sni-01 challenge for [www.almacenetworks.com](http://www.almacenetworks.com)  
Waiting for verification…  
Cleaning up challenges  
Failed authorization procedure. [www.almacenetworks.com](http://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](http://www.almacenetworks.com)”

IMPORTANT NOTES:

- The following errors were reported by the 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

---

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 2:18pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/2 "2017-08-02T14:18:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 2, 2017, 4:45pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/3 "2017-08-02T16:45:40Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 4:47pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/4 "2017-08-02T16:47:36Z")

</div>

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](http://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.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 2, 2017, 4:52pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/5 "2017-08-02T16:52:58Z")

</div>

Oh, are you running this `--duplicate` command _on the other server_ right now?

---

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 4:55pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/6 "2017-08-02T16:55:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 2, 2017, 5:03pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/7 "2017-08-02T17:03:28Z")

</div>

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`?

---

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 5:06pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/8 "2017-08-02T17:06:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 2, 2017, 5:06pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/9 "2017-08-02T17:06:49Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 5:08pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/10 "2017-08-02T17:08:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 2, 2017, 5:13pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/11 "2017-08-02T17:13:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nedwards](https://avatars.discourse-cdn.com/v4/letter/n/eb9ed0/32.png) [@nedwards](https://community.letsencrypt.org/u/nedwards)\
**Post date:** [August 2, 2017, 5:16pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/12 "2017-08-02T17:16:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [September 1, 2017, 5:16pm UTC](https://community.letsencrypt.org/t/issues-requesting-a-duplicate-cert-for-secondary-web-server/39382/13 "2017-09-01T17:16:35Z")

</div>

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