Letsencrypt creating wrong certificates?

Help
1

Please fill out the fields below so we can help you better.

My domain is: cloud.aegee-eindhoven.nl

I ran this command: sudo certbot certonly -d www.aegee-eindhoven.nl -d myadmin.aegee-eindhoven.nl -d cloud.aegee-eindhoven.nl -d aegee-eindhoven.nl

It produced this output: Congratulations! Your certificate and chain have been saved at…

My operating system is (include version): Debian 8

My web server is (include version): nginx

My hosting provider, if applicable, is: NA

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

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

Description:

I had an old server in which I used letsencrypt to generate certificates for some *.rugebiker.com and *.aegee-eindhoven.nl domains. I just installed a new server and I tried to generate certificates (only for *.aegee-eindhoven.nl domains) using the command above. After validating using the webroot process that I am the owner of those domains, it printed “Congratulations” message, saying also where it stored the certificate. I added the certificate to my nginx configuration (done this many other times) and I know I am pointing to the generated one, and when I try to login to https://cloud.aegee-eindhoven.nl, all browsers give me a certificate error. Firefox prints the following message:

cloud.aegee-eindhoven.nl uses an invalid security certificate. The certificate is only valid for the following names: aegee.rugebiker.com, apps.rugebiker.com, etherpad.rugebiker.com, git.rugebiker.com, mail.rugebiker.com, mattermost.rugebiker.com, myadmin.rugebiker.com, owncloud.rugebiker.com, smtp.rugebiker.com, www.rugebiker.com Error code: SSL_ERROR_BAD_CERT_DOMAIN

So why does firefox tells me that this certificate is for *.rugebiker.com domains when I generated it for *aegee-eindhoven.nl domains?

Thanks in advance :slight_smile:

(In the new server I did a fresh install of letsencrypt, so I didn’t copied at all any letsencrypt folder nor configuration from the old one)

2

Whilst it’s not technically impossible that Let’s Encrypt screwed up here, it is unlikely. Let me suggest a divide and conquer strategy. First, go to the server which you believe should serve up the cloud.aegee-eindhoven.nl certificate, examine the configuration file and use a tool like openssl to examine the certificate mentioned in that file

openssl x509 -noout -text -in /some/file/name/from/nginx/configuration/goes/here

Hopefully that’s the certificate you asked for from Let’s Encrypt, for cloud.aege-eindhoven.nl, but if it’s not, you have narrowed down the problem to why this file isn’t what you expected.

If that IS the right certificate, but the web server sends visitors the wrong one, you need to examine the server configuration. Do you have a mistake in DNS? In the web server config?

2 Likes
3

So writing the commant you suggested:
openssl x509 -noout -text -in /some/file/name/from/nginx/configuration/goes/here
actually prints the correct names:

X509v3 Subject Alternative Name:
DNS:aegee-eindhoven.nl, DNS:cloud.aegee-eindhoven.nl, DNS:myadmin.aegee-eindhoven.nl, DNS:www.aegee-eindhoven.nl

so then I’m guessing my problem is with nginx. Maybe is because on the way I have my servers:
My DNS are pointing to my old server where nginx receives the request and forwards it to a port connected through a reverse ssh tunnel to my new server, where another nginx receives the final request. My guess now is that then somehow the first (old) server receives the petition and tries to decrypt it itself, and then forwards the request to the new server.

I can confirm this theory as even if I disable in the new server the ssl, I still receive the warning in firefox that the certificate sent is pointing to different names.

In my old server, this is the nginx configuration:

server {
    listen 443;
    server_name cloud.aegee-eindhoven.nl;
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_pass         https://127.0.0.1:3041;
    }
}

any idea then why this server is sending the certificate instead of just forwarding the request to the other server? Thanks!

4

It is not possible to “just forward” with this setup.

To talk to the remote client at all, even just to find out what resource it is requesting, the nginx server must negotiate with the client a successful TLS connection, and to do this it must present a certificate. In fact your configuration specifies the server name - but even to ask for the name requires beginning the TLS connection.

If you want to really “just forward” you must do this with an IP tunnel, or with NAT, not by having an nginx configured as proxy.

In fact, many people have a setup like yours, but intentionally so that they can do all their certificate management from the nginx server, while running whatever software they like at the backend to actually write HTTP answers.

2 Likes
5

Ok thanks for the info, that cleared things :slight_smile: So now in the old server I created this configuration:

server {
    listen 443 ssl;
    server_name aegee-eindhoven.nl *.aegee-eindhoven.nl;
        ssl_certificate /etc/letsencrypt2/www.aegee-eindhoven.nl/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt2/www.aegee-eindhoven.nl/privkey.pem;
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_pass         http://127.0.0.1:3039;
    }
}

In which I can successfully call https://cloud.aegee-eindhoven.nl and this server will receive it, decrypt the SSL and then send the request through the proxy (on port 3039 which is the 80 on the other server) without encryption. So now, is there a way to encrypt also with SSL this traffic between both servers?
Thanks!

6

Since it's going through an SSH tunnel it's already encrypted and adding TLS is a waste of resources.

7

Oh okok. Thanks a lot both of you :slight_smile: You helped me a lot! I will mark this as solved.

8

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