Koozali.org: home of the SME Server
Obsolete Releases => SME 9.x Contribs => Topic started by: ElFroggio on December 24, 2016, 05:15:57 PM
-
I'm trying to install the letsencrypt certificates. I tried to follow:
https://wiki.contribs.org/Letsencrypt (https://wiki.contribs.org/Letsencrypt)
I did step 2 (prerequisite) and 3 (installation)
When I checked it with https://www.ssllabs.com/ssltest/ (https://www.ssllabs.com/ssltest/) I get:
Trusted No NOT TRUSTED
This means most of my https do not work in Chromium & Firefox
What did I miss?
config show modSSL
modSSL=service
CertificateChainFile=/etc/dehydrated/certs/ethelbert.911networks.com/chain.pem
CommonName=ethelbert.911networks.com
TCPPort=443
access=public
crt=/etc/dehydrated/certs/ethelbert.911networks.com/cert.pem
key=/etc/dehydrated/certs/ethelbert.911networks.com/privkey.pem
status=enabled
The next question could be related: I did not do the step 8 (Install with John Crisp contrib) which I thought is the alternative to step 3/3.1 (dehydrated).
or should I undo and only do the step 8 (Install with John Crisp contrib) the doc is not clear
Any suggestion?
Thanks
Syv
-
Right now, ethelbert.911networks.com is using a GeoTrust certificate, not a Let's Encrypt one.
-
Right now, ethelbert.911networks.com is using a GeoTrust certificate, not a Let's Encrypt one.
Yes. I reverted back to my original certificate
Thanks
/Syv
-
Yes. I reverted back to my original certificate
Makes it kind of hard to troubleshoot. But to your question, John's contrib is an alternative to manually installing dehydrated, so you don't need to (and shouldn't) do both.
Did you set it to use the staging CA? That would explain the cert being untrusted.
-
Did you set it to use the staging CA? That would explain the cert being untrusted.
Yes I did the staging yesterday. I uncommented the config:
It should look like this:
# CA="https://acme-staging.api.letsencrypt.org/directory"
Then this morning, I recommented the staging and re-run:
dehydrated -c
Should I delete it all and restart?
Thanks
Syv
-
If you got your cert from the staging server, SSLLabs would report it as being untrusted, but the cert should be there, it should have the right hostname(s) on it, etc. If all that worked, then you're almost done. You've already commented out the line setting it to use the staging CA, so the only thing left is to run
dehydrated -c -xThe -x flag tells it to go ahead and request a new cert, even though your existing cert isn't about to expire. Without it, the dehydrated script will see that your cert still has more than 30 days' of validity left and won't renew it.
-
If you got your cert from the staging server, SSLLabs would report it as being untrusted, but the cert should be there, it should have the right hostname(s) on it, etc. If all that worked, then you're almost done. You've already commented out the line setting it to use the staging CA, so the only thing left is to run
dehydrated -c -xThe -x flag tells it to go ahead and request a new cert, even though your existing cert isn't about to expire. Without it, the dehydrated script will see that your cert still has more than 30 days' of validity left and won't renew it.
1. Thank you for spending the time and explaining it to me. Very appreciated. :-)
2. Can I update and clarify the documentation? because it doesn't say (or I didn't see it) in the 1st portion that I should run:dehydrated -c -x
Thanks
Syv
-
The -x flag is only necessary if you already have certificates that are still good for more than 30 days, but you want to replace them anyway. It isn't something you'd use normally with that script (and it absolutely isn't something you should include in its cron job).