Cert valid on sub-subdomain, but not subdomain

Help
1

I’m trying to install a certificate on our subdomain and on our subdomain. The domains are:

https://logos.e-handoff.net

and

https://ouhsc.logos.e-handoff.net

The latter seems to work fine; however, the first does not. In fact, the certificate information for the first shows that the certificate was issued to https://ouhsc.logos.e-handoff.net, not to https://logos.e-handoff.net.

I can’t attempt to re-issue the certificate for https://logos.e-handoff.net right now because I’ve tried too many times over the past five days.

We are using Nginx 1.10.3 on Ubuntu 16.04.1.

Any insight that any of you can offer would be greatly appreciated.

TIA

2

Sounds like the configs are crossed and using the wrong certs.
Please show:
grep -Eri 'listen|virtual|:80|:443|server_name|server_alias|ssl_cert' /etc/nginx/

3

Thanks. Here is the output of that command:

/etc/nginx/uwsgi_params:uwsgi_param SERVER_NAME     $server_name;
/etc/nginx/fastcgi.conf:fastcgi_param  SERVER_NAME        $server_name;
/etc/nginx/sites-available/zulip-enterprise:    listen 80;
/etc/nginx/sites-available/zulip-enterprise:    listen 443;
/etc/nginx/sites-available/zulip-enterprise:    ssl_certificate /etc/ssl/certs/zulip.combined-chain.crt;
/etc/nginx/sites-available/zulip-enterprise:    ssl_certificate_key /etc/ssl/private/zulip.key;
/etc/nginx/sites-available/default:     listen 80 default_server;
/etc/nginx/sites-available/default:     listen [::]:80 default_server;
/etc/nginx/sites-available/default:     # listen 443 ssl default_server;
/etc/nginx/sites-available/default:     # listen [::]:443 ssl default_server;
/etc/nginx/sites-available/default:     server_name _;
/etc/nginx/sites-available/default:     # pass the PHP scripts to FastCGI server listening on 
127.0.0.1:9000
/etc/nginx/sites-available/default:# Virtual Host configuration for example.com
/etc/nginx/sites-available/default:#    listen 80;
/etc/nginx/sites-available/default:#    listen [::]:80;
/etc/nginx/sites-available/default:#    server_name example.com;
/etc/nginx/fastcgi_params:fastcgi_param  SERVER_NAME        $server_name;
/etc/nginx/scgi_params:scgi_param  SERVER_NAME        $server_name;
/etc/nginx/snippets/snakeoil.conf:ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
/etc/nginx/snippets/snakeoil.conf:ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
4

Please show file:
/etc/nginx/sites-available/zulip-enterprise

[the only one with 443 and cert]

5

Here ya go:

server {
listen 80;
return 301 https://$host$request_uri;
}

include /etc/nginx/zulip-include/upstreams;

server {
listen 443;

ssl on;
ssl_certificate /etc/ssl/certs/zulip.combined-chain.crt;
ssl_certificate_key /etc/ssl/private/zulip.key;

location /user_avatars {
    add_header X-Content-Type-Options nosniff;
    add_header Content-Security-Policy "default-src 'none' img-src 'self'";
    include /etc/nginx/zulip-include/uploads.types;
    alias /home/zulip/uploads/avatars;
}

location /local-static {
    alias /home/zulip/local-static;
}

include /etc/nginx/zulip-include/certbot;
include /etc/nginx/zulip-include/app;
include /etc/nginx/zulip-include/uploads.route;

}

6

This file needs (twice - in the 80 and 443 blocks):
server_name your.domain.name;
server_alias www.your.domain.name;

[or something like that]

7

What specifically is going wrong?

What ACME client are you using?

You've issued a lot of certificates for those three names recently. Can you still use them? Your software should let you modify the web server configuration without issuing new certificates.

If the ACME client you're using is Certbot, what does "sudo certbot certificates" or "sudo ./certbot-auto certificates" or whatever say?

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

In Nginx, that would be "server_name your.domain.name www.your.domain.name;".

1 Like
8

shows (reduced to relevant)

Shows only one port 80 listening vhost and only one port 443 listening vhost.
[neither of which use exact server_name nor server_alias - just "_"(default)]
Which explains why all his port 443 connections get the same cert.
And why any new named cert issued will simply overwrite the previous one.

9

Hi all,

The problem seems to be that even though the ouhcs.logos.e-handoff.net certificate does not exist on the server, it’s the certificate that nginx is serving up, and it shows as the valid certificate for both sites.

Firefox shows the following:

ouhsc.logos.e-handoff.net uses an invalid security certificate.

The certificate is only valid for the following names:
  logos.e-handoff.net, ouhcs.logos.e-handoff.net

The command $ sudo certbot certificates generates the following:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Attempting to parse the version 0.29.1 renewal configuration file found at /etc/letsencrypt/renewal/logos.e-handoff.net.conf with version 0.28.0 of Certbot. This might not work.
Attempting to parse the version 0.29.1 renewal configuration file found at /etc/letsencrypt/renewal/logos.e-handoff.net-0002.conf with version 0.28.0 of Certbot. This might not work.
Attempting to parse the version 0.29.1 renewal configuration file found at /etc/letsencrypt/renewal/logos.e-handoff.net-0001.conf with version 0.28.0 of Certbot. This might not work.
Attempting to parse the version 0.29.1 renewal configuration file found at /etc/letsencrypt/renewal/ouhsc.logos.e-handoff.net.conf with version 0.28.0 of Certbot. This might not work.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: logos.e-handoff.net
    Domains: ouhcs.logos.e-handoff.net logos.e-handoff.net
    Expiry Date: 2019-03-14 18:14:18+00:00 (VALID: 84 days)
    Certificate Path: /etc/letsencrypt/live/logos.e-handoff.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/logos.e-handoff.net/privkey.pem
  Certificate Name: logos.e-handoff.net-0002
    Domains: logos.e-handoff.net
    Expiry Date: 2019-03-19 17:33:09+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/logos.e-handoff.net-0002/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/logos.e-handoff.net-0002/privkey.pem
  Certificate Name: logos.e-handoff.net-0001
    Domains: logos.e-handoff.net ouhsc.logos.e-handoff.net
    Expiry Date: 2019-03-19 17:27:40+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/logos.e-handoff.net-0001/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/logos.e-handoff.net-0001/privkey.pem
  Certificate Name: ouhsc.logos.e-handoff.net
    Domains: ouhsc.logos.e-handoff.net
    Expiry Date: 2019-03-17 19:30:47+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/ouhsc.logos.e-handoff.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/ouhsc.logos.e-handoff.net/privkey.pem
10

That's it.

You just have to modify your Nginx configuration to use one of the other certificates.

After doing that, you can use "sudo certbot delete" to delete any certificates you no longer need.

1 Like
11

I seem to have run up against the certificate limit again. I deleted the keys as suggested, fixed my nginx config file, but it still wasn’t working. So I deleted the certificates, ran certbot again, and was unable to create any certificates. Is there a way around the “5 certs per week” limit?

12

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