Failed authorization procedure. community.ilp.moe (tls-sni-01)

1

Failed authorization procedure. community.ilp.moe (tls-sni-01): tls :: The server experienced a TLS error during DV :: Failed to connect to host for DVSNI challenge, anime.ilp.moe (tls-sni-01): tls :: The server experienced a TLS error during DV :: Failed to connect to host for DVSNI challenge, music.ilp.moe (tls-sni-01): tls :: The server experienced a TLS error during DV :: Failed to connect to host for DVSNI challenge, player.ilp.moe (tls-sni-01): tls :: The server experienced a TLS error during DV :: Failed to connect to host for DVSNI challenge, db.ilp.moe (tls-sni-01): tls :: The server experienced a TLS error during DV :: Failed to connect to host for DVSNI challenge

IMPORTANT NOTES:

  • The following ‘tls’ errors were reported by the server:

    Domains: anime.ilp.moe, community.ilp.moe, db.ilp.moe,
    music.ilp.moe, player.ilp.moe
    Error: The server experienced a TLS error during DV

    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
    you have an up-to-date TLS configuration that allows the server to
    communicate with the Let’s Encrypt client.

list of domains :
ilp.moe www.ilp.moe stats.ilp.moe db.ilp.moe bot.ilp.moe s.ilp.moe hack.ilp.moe im.ilp.moe pic.ilp.moe music.ilp.moe dittoit.ilp.moe anime.ilp.moe community.ilp.moe multichat.ilp.moe player.ilp.moe

these domains are behind cloudflare so i’m wondering if that’s the issue

2

Some search results suggest this might be related to CloudFlare’s Universal SSL. Would temporarily disabling CloudFlare for those domains to verify this be an option for you?

I can confirm that other modes (e.g. webroot) work with CloudFlare, maybe that’s something you could try as well.

3

i can try. will edit this post if it works.
Pausing cloudflare while running lets encrypt client does solve the issue :smiley: Thanks @pfg

4

Glad it worked out!

@jsha Are there any boulder logs you could grep for this on your end, to check what’s causing this issue with CloudFlare? I suspect Universal SSL might be quite common with Let’s Encrypt users, so this will probably be a thing many people run into. I ran some version of the Go code in boulder where that error is thrown against CloudFlare Universal SSL sites, and it seemed to work fine (implying it’s not some kind of cipher mismatch or something of the like).

Requesting a lot of dot directories (or something similar) might have triggered the WAF and gotten you locked out (there are a lot of bots scanning for exposed SCM files like .git or .svn).

5

maybe Letsencrypt/ACME doesn't support Cloudflare UniversalSSL's ECC 256bit / ECDSA SSL certificates over https ?

6

The TLS SNI challenge requires that you be able to reconfigure TLS for the hostname in question. When a site is behind Cloudflare, or any other CDN, the person directly maintaining that site can’t reconfigure TLS, because TLS is terminated by the CDN. One solution, as discussed here, is to pause CDN service. Another solution is to use the HTTP challenge type. One easy way to use the HTTP challenge type is to use the webroot authenticator in the official Let’s Encrypt client.

3 Likes
7

Honestly i think pausing cloudflare would be easier for me since i use nginx anyway XD.

8

DVSNI challenge means sending Let’s Encrypt certificate back to Let’s Encrypt. You can’t do this while on CloudFlare Universal SSL. If you need to send non-CF cert, you must pay at least $200 for the Business plan.

Of course it doesn’t, just like Comodo, TrustWave or Deutsche Telekom certificates.

9

Ah, I completely misunderstood how tls-sni-01 works. Now the error makes more sense, thanks!

10

Nope, that’s going to crash & burn on renewal. You should be using the webroot authenticator.

1 Like
11

Well i guess ill do that next time and thanks for the info. Also cloudflare has a pause option that i can use whenever i goto renew :stuck_out_tongue:

12

Hi there – CloudFlare TLS PM here.

@jsha is correct in that the tls-sni-01 method is incompatible with any reverse proxy (such as CloudFlare) that you don’t control. To complete the authorization, you have two main options:

  1. Temporary disable CloudFlare (what we call “gray clouding”) for the domain.
  2. You can do this by logging in, clicking on the DNS App, and then clicking the orange cloud on the right-hand side of the row. The graphic should go gray and at that point you can proceed with your validation.
  3. Keep in mind that what this method does is temporarily advertise your origin IP address, so if you’re concerned about exposing that to potential adversaries, you should use the webroot authenticator as @jsha suggests.
  4. Use the webroot authenticator.
  5. This method has the advantage of i) not requiring any temporary changes and ii) not leaking your origin/protected IP addresses.
  6. See below for an overview of the commands that need to be run. For sake of completeness, I’ve provided a sample NGINX config file. Most likely (almost definitely), you’ll already have this server block in place but if not you can use this simple skeleton config.

In either case, you’ll need to manually install the certificate after it’s been issued and downloaded to your server. Follow the appropriate instructions for your HTTP/S server.

Best,
Patrick Donahue
@prdonahue

# set up the web root  (if not already done)
export DOMAIN=yourdomain.com
mkdir -p /var/www/html/$DOMAIN

# set up nginx config (if not already done)
cat > /etc/nginx/conf.d/$DOMAIN.conf << EOF
server {
    listen 80;
    server_name $DOMAIN www.$DOMAIN;

    root /var/www/html/$DOMAIN;
    index index.html;

    location / {
        allow all;
    }

    access_log /var/log/nginx/$DOMAIN.log main;
    error_log /var/log/nginx/$DOMAIN.err debug;
}
EOF

# download and run the letsencrypt client
cd ~/src
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

# after running the following command you’ll be prompted to enter your email address (do it) and     indicate you’ve read license agreement (do it as well)
# ./letsencrypt-auto certonly -a webroot --webroot-path /var/www/html/$DOMAIN -d $DOMAIN -d     www.$DOMAIN --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview
Updating letsencrypt and virtual environment dependencies.......
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly -a webroot --    webroot-path /var/www/html/patentbust.com -d patentbust.com -d www.patentbust.com --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/yourdomain.com/fullchain.pem. Your cert will
   expire on 2016-02-15. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.
3 Likes