Issue with server farm setup

Help
1

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

I ran this command: sudo certbot --nginx

It produced this output:
Which names would you like to activate HTTPS for?

1: alpha.debug
2: alpha.ew-ct.com
3: alpha.ew-ne.com
4: alpha.hzelectric.com
5: alpha.ladedanlar.com
6: alpha.mauriceelectric.com
7: alpha.monarchelectric.com
8: alpha.standardelectric.com
9: alpha.usesi.com
10: alpha.usrenewablesolutions.com
11: alpha.walterswholesale.com
12: alpha.yaleelectricsupply.com

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):2,3,4,5,6,7,8,9,10,12
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for alpha.ew-ct.com
tls-sni-01 challenge for alpha.ew-ne.com
tls-sni-01 challenge for alpha.hzelectric.com
tls-sni-01 challenge for alpha.ladedanlar.com
tls-sni-01 challenge for alpha.mauriceelectric.com
tls-sni-01 challenge for alpha.monarchelectric.com
tls-sni-01 challenge for alpha.standardelectric.com
tls-sni-01 challenge for alpha.usesi.com
tls-sni-01 challenge for alpha.usrenewablesolutions.com
tls-sni-01 challenge for alpha.yaleelectricsupply.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. alpha.ew-ct.com (tls-sni-01): urn:acme:error:una uthorized :: The client lacks sufficient authorization :: Incorrect validation c ertificate for tls-sni-01 challenge. Requested 679179adddfc9cccd9c0095b50ab3fbd. 81d85e0dd5396ecba0b1ec48d92c213d.acme.invalid from 34.206.88.250:443. Received 2 certificate(s), first certificate had names “alpha.ew-ct.com, alpha.ew-ne.com, alpha.hzelectric.com, alpha.ladedanlar.com, alpha.mauriceelectric.com, alpha.mon archelectric.com, alpha.standardelectric.com, alpha.usesi.com, alpha.usrenewable solutions.com, alpha.yaleelectricsupply.com”, alpha.hzelectric.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Inc orrect validation certificate for tls-sni-01 challenge. Requested 66bd75e5c0a9a7 88271482f498f736be.0e8bd758d07e79aed22035d6ee180a79.acme.invalid from 34.206.88. 250:443. Received 2 certificate(s), first certificate had names “alpha.ew-ct.com , alpha.ew-ne.com, alpha.hzelectric.com, alpha.ladedanlar.com, alpha.mauriceelec tric.com, alpha.monarchelectric.com, alpha.standardelectric.com, alpha.usesi.com , alpha.usrenewablesolutions.com, alpha.yaleelectricsupply.com”, alpha.ew-ne.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient author ization :: Incorrect validation certificate for tls-sni-01 challenge. Requested ef0d8e9a1ec9de1760d26190e6ed8393.00fcaf3028fb2e1d0165bb1a31a5b81a.acme.invalid f rom 34.206.88.250:443. Received 2 certificate(s), first certificate had names “a lpha.ew-ct.com, alpha.ew-ne.com, alpha.hzelectric.com, alpha.ladedanlar.com, alp ha.mauriceelectric.com, alpha.monarchelectric.com, alpha.standardelectric.com, a lpha.usesi.com, alpha.usrenewablesolutions.com, alpha.yaleelectricsupply.com”, a lpha.mauriceelectric.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni- 01 challenge. Requested 8dc693ae67cc032d747113398ef93047.3021548afe1ac5f834d3b69 087f9b955.acme.invalid from 34.206.88.250:443. Received 2 certificate(s), first certificate had names “alpha.ew-ct.com, alpha.ew-ne.com, alpha.hzelectric.com, a lpha.ladedanlar.com, alpha.mauriceelectric.com, alpha.monarchelectric.com, alpha .standardelectric.com, alpha.usesi.com, alpha.usrenewablesolutions.com, alpha.ya leelectricsupply.com”, alpha.usesi.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificat e for tls-sni-01 challenge. Requested 84e823f3236063030a26fb8c5fbce4bf.f3d6f608a e83a5c34c5373d653df925f.acme.invalid from 34.206.88.250:443. Received 2 certific ate(s), first certificate had names “alpha.ew-ct.com, alpha.ew-ne.com, alpha.hze lectric.com, alpha.ladedanlar.com, alpha.mauriceelectric.com, alpha.monarchelect ric.com, alpha.standardelectric.com, alpha.usesi.com, alpha.usrenewablesolutions .com, alpha.yaleelectricsupply.com”, alpha.standardelectric.com (tls-sni-01): ur n:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorr ect validation certificate for tls-sni-01 challenge. Requested 9965c326474d71396 e234590172dd853.84e6e28c7d690457e45dcd037d338181.acme.invalid from 34.206.88.250 :443. Received 2 certificate(s), first certificate had names “alpha.ew-ct.com, a lpha.ew-ne.com, alpha.hzelectric.com, alpha.ladedanlar.com, alpha.mauriceelectri c.com, alpha.monarchelectric.com, alpha.standardelectric.com, alpha.usesi.com, a lpha.usrenewablesolutions.com, alpha.yaleelectricsupply.com”, alpha.usrenewables olutions.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks suffi cient authorization :: Incorrect validation certificate for tls-sni-01 challenge . Requested 3a1805b9a78de2ec3e5af4b30a26ee27.020e22c838f14bc7483ae69c02059f81.ac me.invalid from 34.206.88.250:443. Received 2 certificate(s), first certificate had names “alpha.ew-ct.com, alpha.ew-ne.com, alpha.hzelectric.com, alpha.ladedan lar.com, alpha.mauriceelectric.com, alpha.monarchelectric.com, alpha.standardele ctric.com, alpha.usesi.com, alpha.usrenewablesolutions.com, alpha.yaleelectricsu pply.com”, alpha.monarchelectric.com (tls-sni-01): urn:acme:error:unauthorized : : The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 1403c83f0b832510d61256a27741b32b.92b4f2c3ac5 3bc60f914b3fc1944d3c0.acme.invalid from 34.206.88.250:443. Received 2 certificat e(s), first certificate had names “alpha.ew-ct.com, alpha.ew-ne.com, alpha.hzele ctric.com, alpha.ladedanlar.com, alpha.mauriceelectric.com, alpha.monarchelectri c.com, alpha.standardelectric.com, alpha.usesi.com, alpha.usrenewablesolutions.c om, alpha.yaleelectricsupply.com”, alpha.ladedanlar.com (tls-sni-01): urn:acme:e rror:unauthorized :: The client lacks sufficient authorization :: Incorrect vali dation certificate for tls-sni-01 challenge. Requested 39ef178730596e8da5dddc156 9b42cf4.76e4c2dfb01469b0f5c2c2f4662b530c.acme.invalid from 34.206.88.250:443. Re ceived 2 certificate(s), first certificate had names “alpha.ew-ct.com, alpha.ew- ne.com, alpha.hzelectric.com, alpha.ladedanlar.com, alpha.mauriceelectric.com, a lpha.monarchelectric.com, alpha.standardelectric.com, alpha.usesi.com, alpha.usr enewablesolutions.com, alpha.yaleelectricsupply.com”, alpha.yaleelectricsupply.c om (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient auth orization :: Incorrect validation certificate for tls-sni-01 challenge. Requeste d 4c6f5073472253b562b6dc2b3d11588a.2ef0ac86d4ef0ab9d327d7e5ca1dc313.acme.invalid from 34.206.88.250:443. Received 2 certificate(s), first certificate had names “alpha.ew-ct.com, alpha.ew-ne.com, alpha.hzelectric.com, alpha.ladedanlar.com, a lpha.mauriceelectric.com, alpha.monarchelectric.com, alpha.standardelectric.com, alpha.usesi.com, alpha.usrenewablesolutions.com, alpha.yaleelectricsupply.com”

IMPORTANT NOTES:

My web server is (include version): NGINX

The operating system my web server runs on is (include version): Ubuntu 16.04

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

I have 4 servers for this environment and I am trying to set them all up with autorenewing certs. The servers are going to be in an AWS load balancer ultimately. The first server worked fine, but the second throw the above errors.

2

Hi @usesi-sarnold

The TLS-SNI challenge needs to create a temporary certificate and serve it via SNI.

It looks like certbot was not able to bind the temporary certificates.

Andrei

3

Does this mean I can’t have the cert on multiple servers? Sorry, I am a little new to this.

4

Hi @usesi-sarnold,

Can you tell us a little more about your setup? It looks like you only have one IP address, but maybe you have some kind of load balancer in place?

A certificate, once issued, can be shared among as many certificates as you like, but some of the methods that Let’s Encrypt uses to prove your control over the domain name before issuing the certificate don’t interact very smoothly with some kinds of load balancer, proxy, round-robin, or anycast setups.

5

I have 2 EC2 instances on AWS that are not yet, but going to be setup inside a Load Balancer on AWS. Both EC2 instances have vhosts in nginx serving the same set of domains (alpha.site.com). I ran the commands “certbot --nginx” on the first server and it worked fine. I tried it on the second server and it failed. They have different public IPs, there is no proxy setup right now and the DNS for the domains is pointed at the first server right now. As I am typing this, I am guessing that is my problem that the DNS points to the public IP on the first server so I can’t set it up on the second. So I guess I need them to be in the Load Balancer with the same entry IP for it to work?

Thanks,
Steve

6

I’m not sure how the AWS load balancer works or whether it’s compatible by default with any of the methods that Certbot uses to prove your control over domain names (but I’m happy to figure this out if you can find out more about how the load balancer works).

Let’s Encrypt does ultimately depend on DNS and tests using the information in DNS in order to decide whether someone requesting a certificate is authorized to receive that certificate. The certbot --nginx form uses a particular method to prove control over the domain name which requires receiving an inbound TLS connection on port 443 on the IP address that is listed in DNS for each domain name that will be covered by the certificate.

This definitely means that DNS records have to point at the machine that you’re running certbot --nginx on in order for that process to work. However, this is not likely to work behind any sort of load balancer unless there is some way to tell the load balancer to route the TLS probe connections to each server machine at the moment that that particular machine is running certbot --nginx.

There are other methods of obtaining certificates from Let’s Encrypt, which Certbot can support, though not using certbot --nginx (you have to use other Certbot plugins to request their use). The DNS-01 method is most likely to work smoothly when there are multiple server instances behind a single IP address and/or DNS name, as long as the DNS records can be updated via an API and each device requesting a certificate has access to use that API to add DNS records. In that case, the certificate authority will verify the added DNS records and then will be happy to accept that each server has independently proven its right to receive certificates covering each domain name.

If that’s not acceptable for security or policy reasons, it may be best to have some kind of centralized server requesting the certificates on behalf of all of the instances, and/or share certificates, once issued, across multiple server instances.

7

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