Incorrect validation certificate for tls-sni-01 challenge

I think this issue might be related to this… I had a holding page running on apache on same server for this domain, I have since attached a second elastic IP to this server, I then listen on this for all NGINX / Node apps and keep the original IP for apache. That has been working fine and I have managed to issue cirtificates via certbot for both. I went to move a domain from the apache IP to the NGINX one. I repointed it and figured I should delete the cirtificate and re issue it via Nginx (not sure if this was a mistake?). I delete using sudo certbot delete command, seemed fine but I now can’t re issue the certificate using sudo certbot --nginx -d I have since tried to upgrade to http but this has not helped.

Upgraded by:
$ sudo apt-get update

$ sudo apt-get install software-properties-common

$ sudo add-apt-repository universe

$ sudo add-apt-repository ppa:certbot/certbot

$ sudo apt-get update

$ sudo apt-get install certbot python-certbot-nginx `

Any help is really really appreciated, I’m a front-end dev and this is really stretching my knowledge! :slight_smile:

My domain is:

I ran this command:

sudo certbot --nginx -d
#also tried this
sudo certbot --nginx

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1):

Which names would you like to activate HTTPS for?


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 4
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for
TLS-SNI-01 is deprecated, and will stop working soon.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (tls-sni-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested c151a301354102aa9bcf9c3b0fc4cd03.92aeac2559c4e49da80bffd1640e2f3d.acme.invalid from Received 2 certificate(s), first certificate had names “,”


  • The following errors were reported by the server:

    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    from Received 2 certificate(s), first certificate
    had names “,”

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

My web server is (include version):

T3 Amazon Ec2 instance running Ubuntu16.04.5 LTS (GNU/Linux 4.4.0-1075-aws x86_64)

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

Ubuntu16.04.5 LTS

My hosting provider, if applicable, is:


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


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


The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):


Hi @JonCatmull

tls-sni-01 is dead, support ends 2019-03. So use

sudo certbot --nginx --dry-run --preferred-challenges http -d -d

to switch to http validation and to create a test certificate. If that works, remove the --dry-run to create a correct certificate. If that doesn't work, share the output.

PS: You should always create one certificate with both domain names (www + non-www), if both names have dns entries. So both connections are secure.

Hi @JurgenAuer,

Tried it but got this

sudo certbot --nginx --dry-run --preferred-challenges http -d -d

–dry-run currently only works with the ‘certonly’ or ‘renew’ subcommands (‘run’)

$ sudo certbot --nginx renew --dry-run --preferred-challenges http -d -d

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

Currently, the renew verb is capable of either renewing all installed certificates that are due to be renewed or renewing a single certificate specified by its name. If you would like to renew specific certificates by their domains, use the certonly command instead. The renew verb may provide other options for selecting certificates to renew in the future.`

Then add the certonly parameter.

1 Like

AH ok thanks,

This seems to have worked:

So does this mean I just need to modify my nginx config to redirect to https and ref the certificate?

Thanks for the extra advice!

1 Like

Yep, there

is a new certificate, created today. But you have used the certonly parameter with the productive system.

Normally, certbot should do that. Try

sudo certbot --nginx -d -d

perhaps Certbot should ask something like: "There is already a certificate, do you want to reinstall?"

Checked your domain, there is one problem ( ):

Your www - version has the correct certificate with both domain names:
expires in 90 days, - 2 entries

So you have a new certificate.

But your non-www version doesn't use this certificate:

Domainname Http-Status redirect Sec. G 301 0.050 D 301 0.050 A 200 5.357 N
Certificate error: RemoteCertificateNameMismatch 200 5.736 B

Instead, this domain uses
expires in 90 days, - 2 entries

so the name doesn't match.

So check your server blocks.

  • you have no block with server_name, so add this domain name to your www - block
  • the name is at the wrong place. So remove it there and add it to your www server block

Thanks again Juergen.

I’m very new to NGINX and server side stuff.

This is my config (exl. location blocks)

server {


root /var/www/;

index index.html;

location / {} # location poxies

listen xxx.xx.xx.xx:443;

ssl_certificate /etc/letsencrypt/live/;

ssl_certificate_key /etc/letsencrypt/live/;

include /etc/letsencrypt/options-ssl-nginx.conf;

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;


server {

listen xxx.xx.xx.xx:80;


return 301 $scheme://$request_uri;


server {

if ($host = {

return 301 https://$host$request_uri;


listen xxx.xx.xx.xx:80;


return 404;


Am i right in thinking I should change

return 301 $scheme://$request_uri;


return 301$request_uri;

There is no server defined with and port 443

So change



so both domains use the same (correct) certificate.

The redirects are not perfect, but that's another thing. A wrong certificate is always bad.

Ok I get it what you mean. But if i define both server names as you say what is the best way to handle the redirect to www. ? I appreciate you help and don’t wnt to take up any more of your time but if you can point me in the right direction in terms of improving my redirects it would be really appreciated.

It's the first step. First the vHost configuration should be ok - with correct working certificates.

But I see, you have rechecked your domain -

And voilà - there is a Grade B, all connections are secure, all redirects are ok.

Domainname Http-Status redirect Sec. G 301 0.050 A 301 0.047 A 301 5.270 B 200 5.397 A

So you have 2 correct redirects http -> https and one correct redirect https + not preferred version -> https + preferred version.

Your https + www + http status 200 version has already the HSTS header.

So you can add the same header to your https + non-www + http status 301 version, then it's Grade A.

Juergen thanks again for your help!

Grade A achieved! :slight_smile:


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