Ubuntu 14.04 invalid security certificate


#1

Referring this topic:

I changed in vhost configuration as instructed:

Change it to SSLCertificateFile /etc/letsencrypt/live/your-domain.com/fullchain.pem and SSLCertificateKeyFile /etc/letsencrypt/live/your-domain.com/privkey.pem.

So I have it like this now:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/www.nuriasol.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.nuriasol.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/www.nuriasol.net/chain.pem

Still I get the invalid certifate error:

nuriasol.net uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is not valid for the name nuriasol.net. Error code: SEC_ERROR_UNKNOWN_ISSUER”

Something stupid I fail to see here?
Originally I followed these instructions:


#2

For some reason, a self-signed certificate is send for loft9004.dedicatedpanel.com. Strangely enough, also the Let’s Encrypt intermediate is send…??

What certificate do you get when you run:

openssl x509 -noout -text -in /etc/letsencrypt/live/www.nuriasol.net/fullchain.pem

#3

hi @Santero

Did you restart your Apache server?

Also run a check as per what @Osiris suggested

Andrei


#4

openssl x509 -noout -text -in /etc/letsencrypt/live/www.nuriasol.net/fullchain.pem

Gives as below, but I have to run it as sudo…? Is that normal.
I did restart Apache.

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:8d:36:a7:2e:ed:36:86:3e:01:74:61:5f:8d:17:d3:32:83
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
Validity
Not Before: Apr 9 02:57:00 2017 GMT
Not After : Jul 8 02:57:00 2017 GMT
Subject: CN=www.nuriasol.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:bc:3f:fd:ee:4c:59:79:17:64:de:46:0c:fd:be:
f8:2e:03:3c:06:6e:b5:d7:61:37:42:21:f6:2f:b3:
2d:ad:49:2b:b7:f0:2f:12:fa:da:4e:2a:cb:12:47:
57:ad:23:31:ef:fc:ee:eb:10:80:33:ac:24:10:f6:
f4:45:73:f6:2b:03:4d:57:6a:95:84:38:bf:77:a5:
05:6c:20:2c:27:05:00:d5:7b:55:e1:c3:d1:ee:8a:
28:2d:b7:19:06:67:42:3a:66:c8:d7:b5:d8:c8:0d:
50:ae:f5:05:88:d5:27:da:d9:c1:ae:be:36:90:81:
4b:1e:ce:5b:e1:63:20:78:1e:dc:39:38:ab:03:b9:
11:0c:50:f0:d1:69:8d:90:d6:e2:64:c1:67:51:6b:
db:29:f8:87:e6:b2:ab:55:f2:04:46:db:58:ba:2a:
83:15:90:5c:ea:f0:ab:25:0e:fb:d2:d6:3f:5f:18:
4b:ec:da:2d:b1:55:7e:60:3d:ee:d0:d6:7e:ff:7a:
10:ef:cd:38:f0:ac:69:d5:8e:55:cf:5a:aa:65:59:
d6:6b:40:ee:38:e9:c3:53:9d:fc:11:61:3c:0f:ce:
39:71:88:08:a3:e1:88:ab:c2:fb:60:40:ed:3a:91:
40:97:59:37:65:1b:d8:b6:2d:32:76:54:c1:0f:c7:
81:6b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
D3:5F:3D:F3:B4:EA:E3:26:9B:0B:98:C4:D8:46:F6:7E:5D:31:EE:A1
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

        Authority Information Access:
            OCSP - URI:http://ocsp.int-x3.letsencrypt.org/
            CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
        X509v3 Subject Alternative Name:
            DNS:www.nuriasol.net
        X509v3 Certificate Policies:
            Policy: 2.23.140.1.2.1
            Policy: 1.3.6.1.4.1.44947.1.1.1
              CPS: http://cps.letsencrypt.org
              User Notice:
                Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
Signature Algorithm: sha256WithRSAEncryption
     8b:a7:1d:85:74:8e:31:75:43:21:d7:18:0c:c4:89:13:59:35:
     2d:4c:a2:7e:72:7a:4c:77:27:87:69:46:63:d7:45:a2:6d:0a:
     86:c3:3a:69:ac:f3:04:3a:65:d2:66:2c:95:33:8b:bf:c8:ac:
     84:65:70:61:22:b7:b1:73:e4:b8:17:46:88:8f:57:cc:10:2b:
     d0:fc:84:09:89:9d:f9:70:a3:a6:fc:7f:51:5b:d8:e1:5a:9a:
     15:14:eb:12:42:a2:cf:87:dc:d1:65:4e:0c:41:52:2f:04:fc:
     86:9b:d9:0c:06:9e:1b:0c:4c:db:a4:49:dc:51:c4:cd:49:fa:
     a2:f2:a3:39:89:6f:dd:b8:e6:f4:70:4a:f4:08:9b:23:e7:09:
     b2:f9:c9:b0:61:38:8b:fd:1b:92:43:5c:16:c5:f7:48:17:fc:
     1a:da:68:83:c8:1f:6f:c3:b8:72:04:ab:17:4d:04:d2:99:4d:
     79:a4:f6:d2:42:39:17:48:14:8f:2c:76:b0:35:b5:61:8a:94:
     d5:6a:6b:ae:72:b0:d5:4f:4d:94:a1:f3:a5:66:fb:9c:ed:2c:
     7a:d8:45:4c:19:2a:34:d1:69:0f:95:df:30:bd:e5:37:df:66:
     d6:00:f8:7e:9e:cd:64:e6:4d:40:0f:c4:3c:5b:eb:ba:61:ff:
     8a:33:94:ed

#5

That’s the certificate for www.nuriasol.net alright (but not for nuriasol.net!). And that is not the certificate send by the webserver…

Did you install those Apache directives in the right <VirtualHost> section?


#6

Hi and thanks.
For some reason there are two virtual host configurations:

nuriasol.net.conf
with a setting for both www.nuriasol.net and nuriasol.net and a redirect a redirect:

<VirtualHost *:80>
ServerAdmin XXXXXXXX
ServerAlias nuriasol.net www.nuriasol.net

   DocumentRoot /home/nuriasol/public_html/

RewriteEngine on
RewriteCond %{SERVER_NAME} =www.nuriasol.net [OR]
RewriteCond %{SERVER_NAME} =nuriasol.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

And nuriasol.net-le-ssl.conf with

ServerAdmin xxxxxxx ServerAlias nuriasol.net www.nuriasol.net
   DocumentRoot /home/nuriasol/public_html/

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/www.nuriasol.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.nuriasol.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/www.nuriasol.net/chain.pem


#7

Probably one with <VirtualHost *:80> for the HTTP requests and the other <VirtualHost *:443> for the HTTPS site. That’s normal and doesn’t explain why your webserver isn’t serving the correct certificate :worried:


#8

Yes, that is correct.
One for 80 and one for 443.

Should I remove the certificate (how?) and try again?


#9

I doubt that’s useful. Somehow there’s a certificate served for loft9004.dedicatedpanel.com.

One thing I saw in your configuration files is you’re using only ServerAlias and not ServerName. This could be a problem for Apache: https://httpd.apache.org/docs/2.4/mod/core.html#servername

You should change:

ServerAlias nuriasol.net www.nuriasol.net

to:

ServerName nuriasol.net
ServerAlias www.nuriasol.net

Also: you have two certificates issued currently:

This is problematic if you’re using both hostnames in a single <VirtualHost> section, because Apache will just serve one certificate for both hostnames. Options are:

  • Split both hostnames in two separate files both with their own <VirtualHost> section pointing to the correct certificate;
  • Get a third certificate but now for BOTH hostnames and use that new certificate in the current <VirtualHost> section.

#10

If I try to ask for a certificate for both, it fails on a timeout now (certbot-auto --apache -d nuriasol.net -d www.nuriasol.net)

I can of course create separate vhost files, but they at the moment only contain the rewrite rule, i.e. they are not pointing to any certificate.
The certificates are mentioned in the nuriasol.net-le-ssl.conf file.
Maybe if I delete that, and put the corresponding

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/www.nuriasol.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.nuriasol.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/www.nuriasol.net/chain.pem
To each vhost file?

I think the problem originally occurred, because I created tha certificate separately for www.nuriasol.net and nuriasol.net, while they were having one vhost file only (with both configured as aliases: I fixed that)


#11

Ok. Thanks guys.
They work now.

Created a vhost file for www.nuriasol.net and for nuriasol.net separately, as there are two certificates because of my mistake…
Then deleted the nuriasol.net-le-ssl.conf file.

Then added the reference to the corresponding certificates on the end of the vhost configurations.
Re-enabled both vhosts and then reloaded apache.

Thanks again for great tips.


#12

That’s because certbot has generated a specific configuration file for the HTTPS site: the nuriasol.net-le-ssl.conf file.

The original file nuriasol.net.conf should contain a <VirtualHost *:80> and the nuriasol.net-le-ssl.conf file contained a <VirtualHost *:443> section, respectively the virtualhost section for HTTP and HTTPS.

Euh, did you add the SSL directives to the <VirtualHost *:80> sections? :worried: Although I’m seeing your HTTPS site actually works, so I guess you added it to the correct virtualhost section :stuck_out_tongue:

Unfortunately, your redirect isn’t working now… If I go to http://www.nuriasol.net I’m seeing an Apache test page. Perhaps you’ve modified your <VirtualHost *:80> sections to <VirtualHost *:443> sections, and now your HTTP site isn’t working any more?


#13

Yes that’s what I did, and for some reason neither is working now: Both are showing the default site.


#14

Well. They are working with the https, but http does not automatically redirect to that.


#15

Ok. Now they work as expexted.
Created Vhosts sections for both 80 and 443 with redirect for both conf files: www.nuriasol.net and nuriasol.net

   <VirtualHost *:80>
   ServerAdmin      XXXXXX
   ServerName www.nuriasol.net
   Redirect permanent / https:/www.nuriasol.net/
   </VirtualHost>
  <VirtualHost _default_:443>
   ServerAdmin      XXXXX
   ServerName www.nuriasol.net

    SSLEngine on etc...

Learned a lot: Longtime project for me to make a few sites https.
Due to complexity and price did not make the effort until now!


#16

And now you can enter your site(s) into https://whynopadlock.com because there are a lot of non-secure resources loaded on the page, which will remove the green padlock and turn it into a “non-secure” variant!

Also, be advised, this redirect variant will give you issues with the webroot authenticator! I don’t know if you’ve used that authenticator or the apache plugin, but when using webroot, Let’s Encrypt requests the token from the HTTP site in the directory /.well-known/acme-challenge/. With this redirect, the path (/.well-known/acme-challenge/tOkEn) is removed when redirecting!

So if your renewal won’t work because you’re using the webroot plugin and this redirect, you now know why :wink:


#17

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