SSL verification for .dev

Can I use Certbot for a .dev domain? .dev domains only work on HTTPS so it does not have HTTP

I am using Nginx on Ubuntu 19.04

Hi @ProfessionalTev,

Yes, you can, and many people do.

The “HTTPS only” policy for .dev is enforced by browsers, not by any other part of the Internet, so you can and should have an HTTP listener on your web server. Most browsers won’t ever talk to it, but the Let’s Encrypt validation bot will (if you use the HTTP-01 challenge method).


I get the error ‘ refused to connect.’

(When I ping the domain: 6 packets transmitted, 6 received, 0% packet loss, time 109ms)

What is the actual domain in question? Does it have port TCP/80 open to the Internet? and yes

the open port part is all right, but you seem to redirect to 443 unconditionnally.

--2019-06-27 20:58:58--
Resolving (
Connecting to (||:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: [following]
--2019-06-27 20:58:58--
Connecting to (||:443... connected.

How would I fix this?

You will want to disable the HTTP to HTTPS redirect at least temporarily, long enough for you to get your LetsEncrypt certificate, at which point you can reenable that redirect once you install the certificate. This will all depend on what web server software you’re using, and if you can give that detail and possibly your software configuration there are people here familiar with most popular webserver packages and can hopefully help.

something like the following could maybe help you

include /etc/nginx/snippets/letsencrypt.conf;
location / {
    return 301 https://$host$request_uri;


location ^~ /.well-known/acme-challenge/ {
	default_type "text/plain";
	root /var/www/letsencrypt;

Where would the first block go (or do I replace the first with the second block)?

Also, what is the location of the config?

you said you were using nginx, so I assumed you were knowledgeable with it. Usually a file named /etc/nginx/nginx.conf contains a lot of complicated parameters. Usually under ubuntu, this file is spread under subdirectories named sites-enabled and sites-available. If you followed this template you already have a file under sites-available soft linked under sites-enabled. This file should contain a server ‘stanza’ (that’s a block surrounded by braces) containing a listen instruction, something like
listen *:443 ssl http2;
There is probably another file containing a server block beginning by listen *:80 that is including the redirect instruction (a return 301 http…)
you have to add the include instruction before as I posted and create in /etc/nginx/snippets the letsencrypt.conf file.


This is my configuration. What do I change here?

Sorry, this can’t be correct. You have a http redirect that works, so you have a server stanza including a listen on port 80. This is where you have to add an exclusion for letsencrypt.

Hi @ProfessionalTev

there is no problem with that redirect. Letsencrypt follows these redirects.

And your configuration is ok, Grade C ( ):

Both versions (non-www and www - /.well-known/acme-challenge/random-filename) are redirected to https.

There is no need to exclude that subdirectory from redirects.

To check your configuration and to find the correct vHost, use

nginx -T
1 Like

oh well, I stand corrected. I have always assumed that the challenge on http was to be handled on http only.
Now I’m curious, how is it working ? if there is not yet any certificate, how can the SSL challenge on port 443 succeed to allow Boulder to read the reply to its challenge ? and if a certificate already exists but is expired, is Boulder ignoring it and reading the reply anyway?

1 Like

A working port 443 is required. Sometimes users send http over port 443, that can’t work.

But it’s not relevant if the certificate is self signed or expired.

So a domain with redirects http -> https and a Grade N (expired) ->> the certificate can be renewed using http-01 validation.

One requirement: Only the standard ports 80 / 443 are checked.

I only stand half corrected then. This is a configuration of the type ‘you need one to get one’. These configurations can lead to grief - as was saying someone only 30 minutes ago on this forum:

In trying I deleted the (working but almost outdated)

Well, I will continue to advice setting up port 80 exceptions :slight_smile:

1 Like

Yep, that’s always bad. But some lessons are hard to learn :wink:

Boulder ignores certificate validation errors of all kinds when following redirects from HTTP to HTTPS during validation of an HTTP-01 challenge. So for example, if an existing certificate is already expired, that won’t be a problem for Boulder’s challenge validation.

The “if there is not yet any certificate” problem should usually not arise in most users’ configurations because the HTTP → HTTPS redirect should normally be set up after the first certificate has been obtained. (That’s what Certbot does, for example—it won’t create this redirect until a certificate has already been successfully installed.)


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