Adding new main domain to existing configuration for Nginx in docker

[Micromegass]

Hi everyone.

I am running an app with a dockerized nginx on an EC2 instance and configured my ssl with Let’s Encrypt. Now I would like another primary domain to that certificate but I fail in doing so.
When I run

sudo docker run -it --rm -v /docker-volumes/etc/letsencrypt:/etc/letsencrypt -v /docker-volumes/var/lib/letsencrypt:/var/lib/letsencrypt -v /docker/letsencrypt-docker-nginx/src/letsencrypt/letsencrypt-site:/data/letsencrypt -v "/docker-volumes/var/log/letsencrypt:/var/log/letsencrypt" certbot/certbot certonly --webroot --email myemail --agree-tos --no-eff-email --webroot-path=/data/letsencrypt -d heatbe.at -d www.heatbe.at -d heatbeat.dev -d www.heatbeat.dev

it fails. If I run the command without -d heatbeat.dev -d www.heatbeat.dev it succeeds in renewing my certificates. Can I extend the certificate for primary domains or is that only possible for subdomains? Or could there be a problem with the .dev domain because of strict https? Or do I need to change my configs of my nginx somehow?

My config:
server {

listen 443 ssl;
server_name heatbe.at;
charset utf-8;
ssl_stapling off;
ssl_stapling_verify off;

ssl_certificate            /etc/letsencrypt/live/heatbe.at/fullchain.pem;
ssl_certificate_key       /etc/letsencrypt/live/heatbe.at/privkey.pem;

    set $my_host $http_host;
    if ($http_host = "heatbe.at") {
          set $my_host "heatbe.at";
    }

    location / {
        proxy_pass http://django:5000;
        proxy_set_header Host $my_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

}

server {
        listen 80 ;
        server_name heatbe.at;
        return 301 https://heatbe.at$request_uri;
}
server {
        listen 80 ;
        server_name www.heatbe.at;
        return 301 https://heatbe.at$request_uri;
}
server {
        listen 443 ;
        server_name www.heatbe.at;
        return 301 https://heatbe.at$request_uri;
        ssl_stapling off;
        ssl_stapling_verify off;

        ssl_certificate           /etc/letsencrypt/live/heatbe.at/fullchain.pem;
        ssl_certificate_key       /etc/letsencrypt/live/heatbe.at/privkey.pem;
}

Really appreciate any kind of help on this. Thanks so much, and thanks for lets encrypt, great tool

My domain is: heatbe.at, heatbeat.dev

My web server is (include version): 16.04

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

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

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

[bruncsak]

You have to create virtual hosts listening on port 80 for the other two domains too.

[JuergenAuer]

Hi @Micromegass

@Micromegass

If I run the command without -d heatbeat.dev -d www.heatbeat.dev it succeeds in renewing my certificates.

sounds that your dev config is wrong / incomplete.

@Micromegass

Can I extend the certificate for primary domains or is that only possible for subdomains?

Normally, that should work.

@Micromegass

Or could there be a problem with the .dev domain because of strict https?

That's not relevant. HSTS and Preloading is great, but that affects only browsers, not raw GET-commands.

What's your port 80 dev config?

[Micromegass]

Hi Juergen, hi bruncsak and thanks for the quick response.

@bruncsak you mean I have to do this in my nginx configuration file or where exactly?

@JuergenAuer the configs of my nginx are all I have… I run this in a docker-container. In my registrar I changed the nameservers pointing to an ElasticIp which I route with Route 53 to my server.

[bruncsak]

@Micromegass

@bruncsak you mean I have to do this in my nginx configuration file or where exactly?

Add this:

server {
        listen 80 ;
        server_name heatbeat.dev;
        return 301 https://heatbe.at$request_uri;
}
server {
        listen 80 ;
        server_name www.heatbeat.dev;
        return 301 https://heatbe.at$request_uri;
}

[Micromegass]

@bruncsak Thank you!! So this is redirecting my heatbeat.dev to heatbe.at, which is actually fantastic, thanks so much (I didn’t even recreate the certs)…

But my problem with that is that I have a third one (heatbeat.de) that should actually be the primary one… So everything should redirect to that one without changing URL… Or in general it would be good to keep the URL names… So I think I need to change the cert somehow, right? Or add it…

Update: Seems like only firefox sometimes redirects… with chrome it is still insecure
Update2: Recreating the cert with this added config gives me:

   Domain: www.heatbeat.dev
   Type:   unauthorized
   Detail: Invalid response from
   https://heatbe.at/.well-known/acme-challenge/rWa_JWWvjvu8pzOL4WMaplOj-3xa0ufTamAPAdJqxvg
   [18.184.35.43]: "<!DOCTYPE html>\n<html lang=\"de\">\n<head>\n
   <meta charset=\"utf-8\">\n  <meta http-equiv=\"x-ua-compatible\"
   content=\"ie=edge\">\n  <titl"```

[bruncsak]

You may play which virtual host the redirection goes. The only thing you have to be careful, that the ACME client should find where to put the challenge and the ACME server should be able to follow the redirections to find the challenge to check it.

[Micromegass]

@bruncsak thanks again! But just to clarify: You mean I should recreate the certificates with this config or not? And should I put the challenge also in my nginx config or where do you mean?

[bruncsak]

I am not so expert in nginx configuration. What is important, that for each of you six domains you have to have (heatbeat.dev, heatbeat.de, heatbe.at) * (with www, w/o www) virtual host listening on port 80 with HTTP. Than you can redirect the traffic as you wish to other virtual host(s) listening on port 443 with HTTPS. You want to put exception for the /.well-known/acme-challenge location not to have redirection OR if the document root for virtualhost listening on port 80 is the same as the virtualhost listening on port 443 then you do not need exception for the redirection.

The nginx configuration is the first step. Only if it is OK, then you may want to generate test certificate (–dry-run). If it is OK too, then you generate the trusted certifcate(s).

[Micromegass]

Ok I think I understand… I will try this, thank you… Last question though: Could I install nginx on my server (without docker) only for the purpose of creating the certificates, then set up auto renewal, and then use those certificates in my nginx that runs in my docker container? Would that work?

[bruncsak]

Try changing the minimum, since it is already running fine with the original two domains. Just add the virtual hosts to the nginx config files, keep it running in docker as before.

[Micromegass]

@bruncsak

Try changing the minimum, since it is already running fine with the origo inal two domains. Just add the virtual hosts to the nginx config files, keep it running in docker as before.

Yes but with the extra virtual hosts I can't really manage to create new certificates. I will try again but it keeps failing.... And it will also be hard to set up auto renewal in docker I think... So it might be easier to start anew, do the certificates outside of docker and then use it inside a container. I just don't know if it's possible.....