DVSNI challenge error on Azure VM

I’m trying to install a certificate on a Ubuntu Virtual Machine running on Microsoft Azure. I’ve configured my A records and CNAME records properly to point to the server (at least that’s what I believe, the domain has been pointing to my the server for a while without problems) but when I run letsencrypt standalone (nginx disabled) and type in my domain, this is what I get:

Requirement already up-to-date: setuptools in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages
Requirement already up-to-date: pip in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages
Requirement already up-to-date: letsencrypt in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages
Requirement already up-to-date: letsencrypt-apache in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages
Requirement already up-to-date: zope.interface in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: setuptools in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: python2-pythondialog>=3.2.2rc1 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: PyOpenSSL in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: pytz in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: parsedatetime in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: configobj in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: acme==0.2.0 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: psutil>=2.1.0 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: six in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: cryptography>=0.7 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: zope.component in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: mock in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: pyrfc3339 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: ConfigArgParse>=0.10.0 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt)
Requirement already up-to-date: python-augeas in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt-apache)
Requirement already up-to-date: requests in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.2.0->letsencrypt)
Requirement already up-to-date: pyasn1 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.2.0->letsencrypt)
Requirement already up-to-date: ndg-httpsclient in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.2.0->letsencrypt)
Requirement already up-to-date: werkzeug in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.2.0->letsencrypt)
Requirement already up-to-date: enum34 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt)
Requirement already up-to-date: ipaddress in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt)
Requirement already up-to-date: idna>=2.0 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt)
Requirement already up-to-date: cffi>=1.4.1 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt)
Requirement already up-to-date: zope.event in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from zope.component->letsencrypt)
Requirement already up-to-date: funcsigs in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from mock->letsencrypt)
Requirement already up-to-date: pbr>=0.11 in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from mock->letsencrypt)
Requirement already up-to-date: pycparser in /home/pigments/.local/share/letsencrypt/lib/python2.7/site-packages (from cffi>=1.4.1->cryptography>=0.7->letsencrypt)
Requesting root privileges to run with virtualenv: sudo /home/pigments/.local/share/letsencrypt/bin/letsencrypt certonly --standalone --verbose
Failed authorization procedure. www.pigments.io (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challe
nge

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.pigments.io
   Type:   urn:acme:error:connection
   Detail: Failed to connect to host for DVSNI challenge`

Am I missing something or doing something wrong?

For the TLS-SNI-01 challenge, port 443 needs to be open. Currently, it’s closed for www.pigments.io.

Thanks, I got this working! Still struggling with the rest of my setup but it seems like I got the certificates correctly. I have one question though: My deploy tool requires crt and .key files, the tutorial I could find uses .pem though and in the live folder I’m getting .pem files as well.

I’m guessing I just need to rename the privkey and another file to the right name with the file ending? Or do I need to grab the crt file from somewhere else?

There’s a very great chance your deploy tool uses PEM encoded files, but uses the extension to make the difference between certificates and private keys… It’s a matter of preference I guess. Let’s Encrypt chooses to use the encoding format of the file as extension and uses the filename to differentiate between the certificates, certificate chain(s) and private key.

I’d recommend a) using the files in /etc/letsencrypt/live/your.domain/ directly or b) symlink to the symlinks in that directory if you really want the .crt and .key files… That’ll save you a renaming/copying step when you’ve renewed the certificate in ±60 days from now.

If your deploy tool needs DER encoded files, you can reencode the certificates with a few simpel OpenSSL commands:

openssl x509 -inform pem -in /etc/letsencrypt/your.domain/cert.pem -outform der -out /path/to/wanted/location/yourdomain.crt
openssl x509 -inform pem -in /etc/letsencrypt/your.domain/chain.pem -outform der -out /path/to/wanted/location/yourdomain-intermediate.crt
openssl rsa -inform pem -in /etc/letsencrypt/your.domain/privkey.pem -outform der -out /path/to/wanted/location/yourdomain.key

But that’s probably not necessary.

Is there a way to figure out if something’s not working properly with my deployment or if it’s the certificate? I’ve downloaded the certificate, it seems like it has been set up correctly with the deployment tool but when you visit the website it redirects to a broken IP via https. Not sure where the issue is coming from and how I can find the origin of error.

If I try and access pigments.io I get a ERR_CONNECTION_REFUSED - as far as I can see the server is not listening / responding on port 443. Is your server listening on port 443 ? what’s your nginx config ?

I’ve fixed the issue :slight_smile: ! All the issues I’ve encountered after downloading the certificates were related to the deployment tool. I’m very excited, thanks a lot :smiley: !