I’m trying to install Let’s Encrypt on Vagrant ubuntu server and it gives me the following messages:
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: example.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
dedeb81434f610b1312ad91ef3a266af.6843458e4ba3d7e8514de7ef0950eb33.acme.invalid
from 93.184.216.34:443. Received 2 certificate(s), first
certificate had names "example.com, example.edu, example.net,
example.org, www.example.com, www.example.edu, www.example.net,
www.example.org"
Domain: www.example.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
6105a2d4bb5099f1e5771ac639c547cd.af58b13cf448147bf69fa479b2734087.acme.invalid
from 93.184.216.34:443. Received 2 certificate(s), first
certificate had names "example.com, example.edu, example.net,
example.org, www.example.com, www.example.edu, www.example.net,
www.example.org"
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.
Am I supposed to only install Let’s encrypt onto Production and not Dev?
This error means that the Apache plugin for Certbot failed to reconfigure your Apache server’s configuration in the course of trying to prove your control over these domain names.
The most common reason for that is an unusual Apache configuration for your virtual hosts, including having multiple virtual hosts defined in a single configuration file (usually in /etc/apache2/sites-available). Could that be the case for your configuration?
I’m interested in setting up on a vagrant instance and before pulling the trigger in production.
Are there any examples that I can follow for this case? I haven’t seen many vagrant and let’s encrypt tutorials…
And it is especially confusing when there are so many different ways to install let’s encrypt on multiple platforms.
Would love some feedback on how to configure nginx config file as well. Thanks!
For simplicities sake, I’d like to make the original default site from nginx use https.
The following is what was inside the default site-available
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name localhost;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
}
# HTTPS server
server {
listen 443;
server_name localhost;
root html;
index index.html index.htm;
ssl on;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
ssl_prefer_server_ciphers on;
location / {
try_files $uri $uri/ =404;
}
}
Oh, sorry! That’s interesting that it tried the DVSNI challenge in your case. Can you tell me exactly what certbot command you ran when getting the error you originally mentioned?
vagrant@vagrant-ubuntu-trusty-64:~$ ./certbot-auto certonly -d example.com -d www.example.com
Requesting root privileges to run certbot...
/home/vagrant/.local/share/letsencrypt/bin/letsencrypt certonly -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Failed to find apache2ctl in PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Place files in webroot directory (webroot)
2: Spin up a temporary webserver (standalone)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for example.com
tls-sni-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.example.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 6d3c4ad2c9be1a599acc96c7d6838760.5327287ae283ce26e5ae4a3c0110f036.acme.invalid from 93.184.216.34:443. Received 2 certificate(s), first certificate had names "example.com, example.edu, example.net, example.org, www.example.com, www.example.edu, www.example.net, www.example.org", example.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested fa0b0bbfafb69679e62239ec5bdb5353.d788a2ae1f1b097bce1421aadf1483b5.acme.invalid from 93.184.216.34:443. Received 2 certificate(s), first certificate had names "example.com, example.edu, example.net, example.org, www.example.com, www.example.edu, www.example.net, www.example.org"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: www.example.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
6d3c4ad2c9be1a599acc96c7d6838760.5327287ae283ce26e5ae4a3c0110f036.acme.invalid
from 93.184.216.34:443. Received 2 certificate(s), first
certificate had names "example.com, example.edu, example.net,
example.org, www.example.com, www.example.edu, www.example.net,
www.example.org"
Domain: example.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
fa0b0bbfafb69679e62239ec5bdb5353.d788a2ae1f1b097bce1421aadf1483b5.acme.invalid
from 93.184.216.34:443. Received 2 certificate(s), first
certificate had names "example.com, example.edu, example.net,
example.org, www.example.com, www.example.edu, www.example.net,
www.example.org"
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.
In this case you probably have an existing web server that’s listening on port 443—do you think that’s right? That’s incompatible with using standalone this way unless you can temporarily shut down the other server.
I have since turned off nginx and updated my /etc/hosts file correct?
vagrant@vagrant-ubuntu-trusty-64:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.0.1 internaltest.example.com # <<<<
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
After rerunning. I have arrived at an nxdomain lookup issue.
vagrant@vagrant-ubuntu-trusty-64:~$ ./certbot-auto certonly --agree-tos --standalone -d internaltest.example.com
Requesting root privileges to run certbot...
/home/vagrant/.local/share/letsencrypt/bin/letsencrypt certonly --agree-tos --standalone -d internaltest.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for internaltest.example.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. internaltest.example.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for internaltest.example.com
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: internaltest.example.com
Type: connection
Detail: DNS problem: NXDOMAIN looking up A for
internaltest.example.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. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
vagrant@vagrant-ubuntu-trusty-64:~$
Is this because it needs to be in production environment to work?
standalone is mostly meant for people who don’t have an existing web server, while webroot is mostly meant for people who do. You can use standalone with an existing web server if you temporarily stop it entirely during the process.
Let’s Encrypt can only issue certificates for publicly-visible domain names, when you actually control the name in question. You can’t get a certificate for a private or internal name that isn’t publicly visible on the Internet in the DNS. (Making your own private CA, or using self-signed certificates, is appropriate for that situation.) With Certbot modes other than manual, the certificate authority will also need to connect directly to your server in order to verify your control of the domain. Other clients, and Certbot’s manual mode, can do this check without directly connecting, if you can edit the DNS records for the domain.
Since I am operating on vagrant. What would be my best option instead of using a self-signed certificate? I want to be able to practice and learn let’s encrypt without having to connect to the internet.
If that is not an option. What are the steps to do this properly in a live server? I want to be able to roll back changes if it doesn’t work out too.
#default nginx
# HTTPS server
server {
listen 443;
server_name internaltest.example.com;
root /usr/share/nginx/html;
index index.html index.htm;
ssl on;
ssl_certificate /etc/letsencrypt/live/internaltest.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/internaltest.example.com/privkey.pem;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
ssl_prefer_server_ciphers on;
location / {
try_files $uri $uri/ =404;
}
}
server {
listen 80;
# listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name internaltest.example.com;
location /.well-known/acme-challenge/ {
alias /var/www/challenges/;
try_files $uri =404;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
}
Vagrant output
vagrant@vagrant-ubuntu-trusty-64:~$ ./certbot-auto certonly --agree-tos --webroot -w /usr/share/nginx/html -d internaltest.example.com
Requesting root privileges to run certbot...
/home/vagrant/.local/share/letsencrypt/bin/letsencrypt certonly --agree-tos --webroot -w /usr/share/nginx/html -d internaltest.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for internaltest.example.com
Using the webroot path /usr/share/nginx/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. internaltest.example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for internaltest.example.com
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: internaltest.example.com
Type: connection
Detail: DNS problem: NXDOMAIN looking up A for
internaltest.example.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. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
A better option for testing and experimenting with Let’s Encrypt is the staging server, which uses the same protocols and verification methods, but without issuing publicly trusted certificates. Its rate limits are significantly higher and its certificates are (I think) not logged to Certificate Transparency. With Certbot, you can use the staging server by adding --staging.
I’m not sure which parts of the Let’s Encrypt technology you want to practice with, but live Internet verification is a super-fundamental part of the technology; in several ways it’s what we’ve spent the longest time developing and implementing. It’s hard for me to see that experiments will be very realistic without including the domain ownership verification challenges.
It’s possible to set up your own copy of the Boulder CA software on your own computer and then perform verifications of yourself and issue certificates to yourself. You can get Boulder from
It can be kind of complex to set up your own copy, but notably there are scripts to run a local Boulder for testing purposes that are used as part of the test suite for Certbot. If you get the Certbot code
and look at tests/boulder-integration.sh, you can see that it actually runs its own copy of Boulder in order to confirm that Certbot can speak to it and request a certificate. (There are a lot of dependencies, and it may not run easily in a specific environment that’s different from the test environment that we use on Travis, so I can’t promise that just running this script will work for you.) If you want to see a lot more detail about how the technology works overall, that might be the best option.
I’m currenly most interested in learning how to best install this and run with an nginx server through a vagrant environment.
Because LE is already doing the certification. I was hoping that I don’t need to install my own certification software to get this to work.
All I’m really trying to do is to add let’s encrypt to the “default” nginx page to test out let’s encrypt. I’m not trying to do anything more than that right now.
Adding staging now provides me with the following error…:
Looks like it is the same error…
vagrant@vagrant-ubuntu-trusty-64:~$ ./certbot-auto certonly --agree-tos -m myEmail@gmail.com --dry-run --test-cert -d internaltest.example.com -w /usr/share/nginx/html/ --nginx --staging
Requesting root privileges to run certbot...
/home/vagrant/.local/share/letsencrypt/bin/letsencrypt certonly --agree-tos -m myEmail@gmail.com --dry-run --test-cert -d internaltest.example.com -w /usr/share/nginx/html/ --nginx --staging
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for internaltest.example.com
Generating key (1024 bits): /var/lib/letsencrypt/snakeoil/0005_key.pem
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. internaltest.example.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for internaltest.example.com
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: internaltest.example.com
Type: connection
Detail: DNS problem: NXDOMAIN looking up A for
internaltest.example.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. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
vagrant@vagrant-ubuntu-trusty-64:~$
My other question is: Do I need to own the domain? I’m just doing this for testing purposes. So I was hoping that I can reroute my hosts file. As in the above comments.
None of the infrastructure operated by the Let’s Encrypt CA itself is able to support the kind of experiments that you’re describing, because it all checks that you really control the (publicly-visible) domain names listed in the certificate. For these internal or educational purposes, the Let’s Encrypt CA isn’t helpful. Specifically, the certificates that we issue are meant for other people to be able to trust, so whatever you say in your own hosts file is completely ignored by Let’s Encrypt.
This is true for the staging server because the staging server is used to practice getting certificates from the production server, so it uses the same verification criteria as the production server.
In order to experiment “privately” or “internally”, you can’t use Let’s Encrypt’s services. You’ll have to make your own CA, or else make the experiment less private by getting your own domain name and then proving to Let’s Encrypt (live, over the Internet) that you really control that specific name.
