I ran the command to get the certificate for the sub-domain “www” and the bare domain in the same command (see below). All went well, with --dry-run and regular command.
Note: When I ran the command www. and non-www where both accessible, (no redirects between the two). PROBLEM: https://www.bluedgeusa.com is seem as a valid SSL certificate by browsers while “https://bluedgeusa.com” is seen as untrusted certificate.
It produced this output:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/bluedgeusa.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/bluedgeusa.com/privkey.pem
My web server is (include version): NodeJs 8.3.0 (I use greenlock-express to server https)
The operating system my web server runs on is (include version): Ubuntu 16.04
My hosting provider, if applicable, is: DigitalOcean
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
Dry-run executes against the staging server and provides an untrusted test certificate. You should not use this in production, staging is to use while troubleshooting issues so you don’t hit rate limits. Once you are able to issue staging certificates, you should drop the dry-run flag and get a real one issued.
Thanks jared. I used -dry-run only at first for the sack of the test, all was well, and then used the command without the --dry-run flag.
Note: I edited my post to reflect the situation better.
@rg305 I had to go back to serving http only pages. I don’t want to have clients seeing a faulty certificate alert. The SSL test online only showed 1 ssl issue for bluedgeusa.com : untrusted certificate.
As long as you don’t force SSL, no one should be forced to see any https pages.
So, you could allow http and https and maybe we can help you resolve the https problem.
At 25th August you issued 7 certificates, 5 of them valid for www.bluedgeusa.com and bluedgeusa.com, 1 of them only valid for bluedgeusa.com and other one only valid for www.bluedgeusa.com and this one is the current certificate used by your web server.
So, you need to take a look to all the certs you have issued:
certbot certificates
And check what is the right path to the one that covers both domains, once you know where it is, you should change your web server config to point to this cert for both domains.
Edit: I forgot to say that the certificate that is being server for bluedgeusa.com is one that you issued using staging server instead of production and that is the reason you receive an error in your browser.
Thx @sahsanu I tried multiple times as from first try i got this issue.
I see only one certificate on my server now: (I did a backup of other certificates before cleaning them from the actual folder)
How do I know which one is the proper one to use from the back up? And how do I make the server use this one instead?
is there a config file?
I ran certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Found the following certs:
Certificate Name: bluedgeusa.com
Domains: bluedgeusa.com,www.bluedgeusa.com
Expiry Date: 2017-11-23 17:59:00+00:00 (VALID: 88 days)
Certificate Path: /etc/letsencrypt/live/bluedgeusa.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bluedgeusa.com/privkey.pem
-------------------------------------------------------------------------------
You can confirm that this is a certificate from the real Let's Encrypt Intermediate certificate authority (currently the Let's Encrypt Authority X3) and that it contains both desired Subject Alternative Names by running:
Then make sure your node server uses the paths specified by certbot:
(Note that we used cert.pem earlier because we don't care about the intermediate certificate when printing to the screen, but you need to use fullchain.pem with most web server software because it indeed needs the intermediate certificate.)
Thx @Patches
I use I use greenlock-express to server https, as I always do. So i “guess” it serves the proper certificates.
This is what I get from your command, anything wrong?
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:5d:d5:be:da:c4:49:6f:74:44:d5:a9:53:32:98:d3:ba:d4
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
Validity
Not Before: Aug 25 17:59:00 2017 GMT
Not After : Nov 23 17:59:00 2017 GMT
Subject: CN=bluedgeusa.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:dc:4d:dd:4c:76:40:62:56:46:cd:ce:c2:45:9b:
31:53:a0:f5:3d:79:30:2e:7d:8a:33:93:de:9d:2e:
5d:5c:00:ff:67:fa:03:03:25:03:f0:10:c1:54:40:
d6:5f:08:4a:fe:a3:74:1e:67:46:13:39:6c:3c:98:
e5:78:9e:b2:fe:6f:d3:24:bb:a9:21:0e:57:6c:57:
ff:c2:d9:03:ea:aa:87:4b:7f:2d:03:3e:96:b8:d4:
de:14:df:48:fd:7d:6b:63:39:13:a0:7f:b1:aa:06:
04:d5:b1:7c:1b:c2:38:09:83:13:a1:02:d2:5c:ac:
90:45:a0:d4:26:28:56:31:13:45:a1:6d:c6:e5:b0:
21:21:ac:62:4f:9f:6f:2d:5c:83:37:2e:16:3a:49:
3c:42:a7:d8:4a:c8:de:dd:55:20:ec:92:52:1b:f4:
9d:7d:b9:95:34:4a:45:99:07:d3:02:01:2d:30:ed:
73:9a:de:b8:bf:b5:37:71:08:62:43:1c:5a:65:9c:
8d:6b:56:a5:fe:35:a6:6a:63:71:e7:14:5b:be:e0:
b5:68:04:ed:30:38:42:51:96:1c:51:f6:76:02:02:
1a:ff:d3:02:0c:9c:dc:7c:c6:6d:a8:72:20:c1:de:
b1:ad:bf:14:d3:50:c9:f4:f2:cf:e6:eb:1e:e2:bd:
93:ab
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:
28:84:12:82:6F:0E:11:62:D2:38:CC:42:32:BB:A3:72:DE:7D:AA:6F
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:bluedgeusa.com, DNS:www.bluedgeusa.com
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
8a:d0:64:1c:c3:04:33:71:e1:bf:f2:bc:0d:9e:15:a4:ce:e0:
9c:61:8d:5f:9a:62:30:d4:41:dd:0c:90:54:b5:98:65:9f:9b:
34:43:7f:7c:5b:c2:5a:55:8b:b3:dc:7e:46:9f:a1:30:e3:be:
5b:1d:a9:d4:22:4a:36:86:1c:81:f6:4b:66:d3:34:74:ae:29:
2d:8a:60:ac:3f:ed:81:3a:47:af:b9:52:df:8c:cf:7d:f4:cb:
9e:c1:c7:d1:87:50:5b:d1:25:32:3b:7f:3d:b4:3a:53:27:e2:
0b:73:1d:af:3d:be:8f:03:d0:66:df:a2:68:29:84:e7:88:5d:
7f:f4:69:db:9e:95:c9:65:75:03:ec:0d:5b:67:8b:33:2a:bd:
32:ac:93:2b:89:93:d6:d3:35:0d:f5:3b:46:85:45:d4:67:f7:
47:f9:fb:41:ba:0d:c4:87:b3:b3:9a:84:de:da:70:4a:89:e7:
f3:8f:87:4f:ec:32:cd:fe:4b:a5:57:96:9c:e7:8c:30:95:b4:
cf:6a:25:14:f8:20:d6:5c:b0:71:a0:47:3a:80:dc:21:3d:e7:
5d:71:d1:75:f3:fd:27:ec:ad:96:57:03:17:13:e9:f4:f7:01:
c8:24:5e:7b:f1:63:df:5a:bb:cd:e5:e6:04:91:ca:d3:5a:c5:
f3:e4:da:25
@Patches I’m confused. I’m not in the impression greenlock issues the certificates. Anyhow, I specified the domain names in the approveDomains. The problem still remain.
function approveDomains(opts, certs, cb) {
if (certs) {
opts.domains = [‘bluedgeusa.com’, ‘www.bluedgeusa.com’]
} else {
opts.email = ‘myemail@gmail.com’;
opts.agreeTos = true;
}
cb(null, { options: opts, certs: certs });
}
If those options don’t make greenlock-express do the right thing after restarting your server, you should file an issue with them to get help from people more experienced with it:
@Patches Thank you for your great help. Greenlock seems to have a limited support, if any.
I will get ride of it and go the Certbot way and load the certificates from nodejs directly.
A cron job will do the periodic renew work…
I would like to thank you all for your help, you are an amazing community !
I have activated https you can now use all http and https version