Obtain cert with nginx with self signed on port 443 using webroot

Server
1

I am running nginx on port 443 using a self signed cert.

self signed cert generation:

openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -days XXX -subj ‘/CN=*.ssldemo.xyz’

certbot:

sudo certbot certonly --webroot --webroot-path /usr/share/nginx/html -d hello.ssldemo.xyz

The DNS wildcard A record points to the machine running certbot.

Here is relevant section of my nginx config.

server {
    listen        443 ssl default_server;
    server_name  _;
    root         /usr/share/nginx/html;

    ssl_certificate "/etc/nginx/certs/cert.pem";
    ssl_certificate_key "/etc/nginx/certs/key.pem";

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

    location / {
    }

}

When I run certbot I get following error:

Domain: hello.ssldemo.xyz
Type: connection
Detail: Could not connect to hello.ssldemo.xyz

I know I am missing something in nginx.conf but can’t figure out what?

Using webroot plugin is it possible to satisfy challenge mechanism securely i.e. by using webserver running on port 443?

I cannot use nginx plugin since I don’t intend to install the cert on the same machine.

2

The webroot plugin uses HTTP through port 80. It can be redirected to HTTPS on port 443, but will always start with port 80…

You can search the community for the reason behind this. Something to do with possible vulnerability when it tries HTTPS immediately, although personally I still don’t get the strict reason behind this after all the previous discussions…

3

The issue is with bulk hosts. They often misconfigure the web server so that a customer (maybe with a site DNS name that appears first alphabetically) is treated as the “default” HTTPS site. So if port 443 webroot validation was allowed this customer could pass the challenge for any site that hasn’t yet enabled HTTPS and shares the same IP address. On a bulk host that might be anyone.

4

Thanks for the response.

  1. Do you mean the LE CA is always going to connect on port 80 to verify the domain when using webroot plugin?
  1. Do you mean I should redirect the call from the LE CA when it tries to pull the temporary file to HTTPS?
    i.e http://hello.ssldemo.xyz/.well-known/acme-challenge/yhda7hnandn should be redirected to
    https://hello.ssldemo.xyz/.well-known/acme-challenge/yhda7hnandn by nginx

But then I would need to keep port 80 open.

  1. On a separate note, when doing the actual issuance of certificates I assume certbot pulls the certificate from LE CA using HTTPS?
5

Yes, to perform the webroot-based challenge, you will need to serve at least a redirect on port 80. For most web servers facing the public this is not a problem (if a visitor just types in your site’s name without https you probably want them to get a web page) but for private services or things that aren’t to be used by browsers that’s not so great.

It was originally intended to permit webroot over HTTPS directly, but the issue with poorly configured bulk hosting caused this to be disabled by Let’s Encrypt.

There are two other proof of control challenges, which may be harder for you to complete, but avoid needing port 80 if that’s a problem. One is DNS, creating a TXT record with certain values, if you have APIs to control your DNS you may be able to use that. Another is the TLS-SNI challenge, which certbot knows how to automate for Apache but could in theory (with enough effort) be passed for other servers.

Alas all your numbered points ended up labelled “1” by the comment system, but the third, about issuance, yes, communication with Let’s Encrypt’s “boulder” server is over HTTPS. For the certificate itself this isn’t a big deal - certificates are public documents, you could get yours from Let’s Encrypt’s archive or from the public Certificate Transparency system, it’s easy for you to check it’s the genuine article, just as a visitor can when your web site shows them the certificate. But for earlier steps in the issuance process it is important to have HTTPS security.

1 Like
6

Yes.

No, it's also perfectly possible to serve the challenge with HTTP on port 80. A redirect isn't necessary per se.[quote="amraks, post:4, topic:20044"]
But then I would need to keep port 80 open.
[/quote]

You could look into the tls-sni-01 challenge if port 80 isn't an option. But yes, for the webroot plugin, port 80 is required.

1 Like
7

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