Koozali.org: home of the SME Server
Obsolete Releases => SME Server 9.x => Topic started by: countzero on June 26, 2016, 12:10:53 PM
-
I can do this:
Reset all SSL certificates to factory default:
rm /home/e-smith/ssl.crt/*
rm /home/e-smith/ssl.key/*
rm /home/e-smith/ssl.pem/*
signal-event post-upgrade
signal-event reboot
Configure SSL certificate:
rm /home/e-smith/ssl.crt/*
rm /home/e-smith/ssl.key/*
rm /home/e-smith/ssl.pem/*
cp server.domain_com.crt /home/e-smith/ssl.crt/
cp server.domain_com.ca-bundle /home/e-smith/ssl.crt/
cp server.domain_com.key /home/e-smith/ssl.key/
Update SSL config:
config setprop modSSL crt /home/e-smith/ssl.crt/server.domain_com.crt
config setprop modSSL CertificateChainFile /home/e-smith/ssl.crt/server.domain_com.ca-bundle
config setprop modSSL key /home/e-smith/ssl.key/server.domain_com.key
Test SSL config:
config show modSSL
modSSL=service
CertificateChainFile=/home/e-smith/ssl.crt/server.domain_com.ca-bundle
TCPPort=443
access=public
crt=/home/e-smith/ssl.crt/server.domain_com.crt
key=/home/e-smith/ssl.key/server.domain_com.key
status=enabled
Apply changes:
signal-event post-upgrade
signal-event reboot
I host multiple domains on SME server 9. I love email pseudonyms, mapping domains to ibays, user quotas for email, etc. I prefer Roundcube for simple email functionality.
The problem is that I typically purchase only 1 SSL certificate per domain. I just now learned that SME server does not really support multiple SSL certificates on a single server.
Not sure where to go from here. The additional SSL certificates are only used for Wordpress websites using HTTPS instead of HTTP.
For a list of available certs: https://www.namecheap.com/security/ssl-certificates/domain-validation.aspx
I guess I need to migrate from PositiveSSL to PositiveSSL Multi-Domain ?
-
I just now learned that SME server does not really support multiple SSL certificates on a single server.
No, it doesn't. You'll need a single certificate covering every hostname you want to use. An easy and free way to do this is using Let's Encrypt; see https://wiki.contribs.org/Letsencrypt for instructions.
-
Hi countzero,
Follow the good contribs: https://wiki.contribs.org/Letsencrypt
Yesterday I installed Let's Encrypt certificate on a SME-9.1 of my best customer.
I think Let's Encrypt change something with the disposition of the letencrypt.sh directory. Now the customer private key to login to Let's Encrypt to ask the certificate is no more the file "/etc/letsencrypt.sh/private_key.pem" but in a directory "/etc/letsencrypt.sh/accounts".
Also, I had to specify the config file with the command:
/etc/letsencrypt.sh/letsencrypt.sh -c --config /etc/letsencrypt.sh/config.sh
Before I didn't have tp specify it and just used:
/etc/letsencrypt.sh/letsencrypt.sh -c
I strongly recommend trying a test certificate first by adding the line #3 (which specify the test CA [acme-staging]) in the config.sh file:
#!/bin/bash
# config.sh
CA="https://acme-staging.api.letsencrypt.org/directory" # CA pour mode TEST.
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
HOOK="/etc/letsencrypt.sh/letsencrypt-hook.sh"
# E-mail to use during the registration (default: <unset>)
CONTACT_EMAIL="admin@your-domain.com"
Don't forget to adjust the domain name in the email "admin@your-domain.com" in the last line and also to use the name admin.
Then you can ask the test certificate with the command specified above.
When you are satisfied with the test, delete the line #3 and also delete/rename the directory "/etc/letsencrypt.sh/accounts" and re-issue the command to ask for a certificate. This time it will be a real certificate.
I did a document which explains all the details:
https://www.micronator.org/PDF/SME/RF-232_SME-9.1_LetsEncrypt/RF-232_SME-9.1_LetsEncrypt.sh.pdf
The SHA-1 checksum
https://www.micronator.org/PDF/SME/RF-232_SME-9.1_LetsEncrypt/RF-232_SME-9.1_LetsEncrypt.sh_SHA-1.txt
It is in French but the pictures are all in English :)
- In this PDF, I didn't put the correction that you have to specify the --config /etc/letsencrypt.sh/config.sh with the command as I found out only yesterday about it. I will correct that in a few days.
- Also, this document used the old disposition for the directory "/etc/letsencrypt.sh/" so adjust as above.
Michel-André
-
I think Let's Encrypt change something with the disposition of the letencrypt.sh directory. Now the customer private key to login to Let's Encrypt to ask the certificate is no more the file "/etc/letsencrypt.sh/private_key.pem" but in a directory "/etc/letsencrypt.sh/accounts".
I reported the issue that this fixed, but I don't remember if the wiki has been updated to reflect it. If not, I'll fix it.
Also, I had to specify the config file with the command:
/etc/letsencrypt.sh/letsencrypt.sh -c --config /etc/letsencrypt.sh/config.sh
letsencrypt.sh was recently changed to expect the config file to be named config rather than config.sh, as it was previously. The wiki has already been updated to reflect this.
When you are satisfied with the test, delete the line #3 and also delete/rename the directory "/etc/letsencrypt.sh/accounts" and re-issue the command to ask for a certificate. This time it will be a real certificate.
...or simply comment out line 3, and there's no need to do anything to /etc/letsencrypt.sh/accounts. That's the point. Previously, letsencrypt.sh generated a single account private key. When you changed CAs, the script didn't realize that and tried to use the same private key, which failed. Now, the account private keys are saved in /etc/letsencrypt.sh/accounts/, and are associated with the CA they belong to.
-
Hi DanB35,
Very nice to know that. I will update my PDF document accordingly this week I hope.
I found https://github.com/lukas2511/letsencrypt.sh/tree/master/docs.
Is there another place to look or to follow for modifications?
Thank you,
Michel-André
-
The best advice I have to tracking changes to letsencrypt.sh is to keep an eye on the commits at https://github.com/lukas2511/letsencrypt.sh/commits/master. At a minimum, if something stops working as expected, see if there's been a commit that would affect it.
The change from config.sh to config was made about a month ago (I have no idea why). I found out about it when I installed an update to John Crisp (@ReetP)'s RPM, ran letsencrypt.sh, and encountered the same error you did. To try to track it down, I looked at the letsencrypt.sh code, and noticed that it was looking for config, not config.sh Looking at the commits confirmed that was an intentional change.
-
The config file should be fixed in my latest rpm.
Let me know if it isn't
I didn't see the thing about the /accounts directory and not sure if it affects the rpm (the version of the letsencrypt script installed may not have that change as yet)
Again if there are changes that ought to be made to my rpm please let me know and I will take a look.
B. Rgds
John
-
The config file should be fixed in my latest rpm.
As far as I can see, it is.
I didn't see the thing about the /accounts directory and not sure if it affects the rpm (the version of the letsencrypt script installed may not have that change as yet)
I don't think the version you've packaged does have that change, but if it does, it shouldn't affect anything. The only change would be that you don't need to rename or delete private_key.pem when you switch from test to enabled.
-
Cool... thanks Dan.
Please keep me posted if there are any changes you feel should be incorporated. I try to keep up but may miss something. I'll try and update the letsencrypt.sh rpm this week.
B. Rgds
John
-
Hi all,
Why they changed:
change PRIVATE_KEY to ACCOUNT_KEY #183: https://github.com/lukas2511/letsencrypt.sh/issues/183
I read the reason they change config.sh to config but I can't find it again.
Michel-ANdré
-
For exactly the reason mentioned in the top of the bug
"the use of the term "PRIVATE_KEY" is overloaded; change to ACCOUNT_KEY where appropriate, avoid confusion with privkey, PRIVATE_KEY_RENEW, and the like"
-
change PRIVATE_KEY to ACCOUNT_KEY #183:
Yeah, that change wasn't so much at issue. It also affects https://github.com/lukas2511/letsencrypt.sh/issues/92, which I'd reported, and makes it unnecessary to delete or rename the account key when switching CAs. That one I understand (likely because I reported it).
I read the reason they change config.sh to config but I can't find it again.
This one I don't understand. I don't really see strong arguments for or against either name, but once you've picked one, I think there'd need to be a compelling reason to change it and break compatibility with your entire installed base. Fixing it isn't that big of a deal, but it just seems unnecessary. There aren't any issues on github that obviously deal with it, so the reason for the change is rather a mystery.
-
config.sh renamed as I guess as it isn't a shell file but just a configuration file. Agree the change was probably unnecessary abd inconvenient but that's the choice of the developer !
-
config.sh renamed as I guess as it isn't a shell file but just a configuration file.
But it is a shell script. All it does is set some variables, but it's a shell script nonetheless. Regardless, it's done, and it's not a huge deal to account for.
-
Ah indeed !!
C'estcla vie :-)
-
https://letsencrypt.org/ (https://letsencrypt.org/) seems to have major sponsors backing the initiative. Probably safe enough to start using for business critical web hosting. GIT 'interfacing' script will guarantee upwards compatibility and cron will make it a fire and forget solution - nice! Complexity is a bit of a concern, but then again SSL is obscure subject matter all by itself no matter how you look at it.
Thanks everyone - this made my day!
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-
https://letsencrypt.org/ (https://letsencrypt.org/) seems to have major sponsors backing the initiative. Probably safe enough to start using for business critical web hosting. GIT 'interfacing' script will guarantee upwards compatibility and cron will make it a fire and forget solution - nice! Complexity is a bit of a concern, but then again SSL is obscure subject matter all by itself no matter how you look at it.
Yup - for general solutions it is wroth a whirl.
Thanks everyone - this made my day!
We try :-)
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Hahahahahahaha...... Seems I need to run and hide :-)
-
https://wiki.contribs.org/Letsencrypt works beautifully. 5 minutes is all it took. I now have multi-domain SSL certs active on Koozali / SME server 9.x. I cried a little.
Thanks everyone; michelandre: Fait: Aucun mot dans la langue anglaise rime avec mois , orange , argent ou violet. Fait: " Rêvé " est le seul mot anglais qui se termine par les lettres " mt "
-
Feedback:
Change /etc/letsencrypt.sh/ to /etc/letsencrypt/. No folder should have the ".sh" suffix". Also mention "letsencrypt.sh -c -x" somewhere, just in case you want to have a closer look at the beautiful output of the initial "letsencrypt.sh -c" command. It all happened so fast. This might be a good spot for it - in the Troubleshooting section, add an extra line to the text already present:
config delprop modSSL crt
config delprop modSSL key
config delprop modSSL CertificateChainFile
if you think contrib needs some changes, please open a bug
if you think documentation should be amended, please request a wiki access ;-)
thank you
-
https://wiki.contribs.org/Letsencrypt works beautifully. 5 minutes is all it took. I now have multi-domain SSL certs active on Koozali / SME server 9.x. I cried a little.
LOL..... Good that it all works for you
Feedback:
Change /etc/letsencrypt.sh/ to /etc/letsencrypt/. No folder should have the ".sh" suffix".
The folder choice was not ours. It's the default and I am not about to change it in the rpm - KISS.
Also mention "letsencrypt.sh -c -x" somewhere, just in case you want to have a closer look at the beautiful output of the initial "letsencrypt.sh -c" command. It all happened so fast. This might be a good spot for it - in the Troubleshooting section, add an extra line to the text already present:
config delprop modSSL crt
config delprop modSSL key
config delprop modSSL CertificateChainFile
Now simply run the following command to force a renew (and update modSSL): "letsencrypt -c -x"
If you read the whole page (always worth doing regardless) you will note that with the RPM it does mention creating the test certificates:
Create test certificates (file is in the path so should be OK)
letsencrypt.sh -c -x
Thanks everyone; michelandre: Fait: Aucun mot dans la langue anglaise rime avec mois , orange , argent ou violet. Fait: " Rêvé " est le seul mot anglais qui se termine par les lettres " mt "
Fact - the lunatics have now taken over the asylum in the UK :lol:
-
if you think contrib needs some changes, please open a bug
Unfortunately as the RPM is not in contribs you cannot open a bug against it.... :-)
I try to watch here as best I can but may miss something.
-
If you read the whole page...
It all worked before I got even halfway down the page. I edited my post to remove some of the clutter but you guys are too fast.
May the forces of evil become confused on the way to your house.
-
It all worked before I got even halfway down the page.
Always worth reading the whole page first ;-)
I edited my post to remove some of the clutter but you guys are too fast.
Only if I am awake and have nothing better to do with my time !!!!
-
To give a little background on the directory name: When Let's Encrypt went public about six months ago, that was the name of both the service and the client software. The client software saved its configuration, certificates, etc, in /etc/letsencrypt. The client has since been renamed to certbot; I'm not sure if the directory in /etc is still the same or not.
letsencrypt.sh is one of many alternate clients that's implemented as a bash script. Naming it such makes perfect sense, with the ".sh" distinguishing it from the original client and describing that it's a shell script. It needs to store data in /etc as well, and shouldn't conflict with /etc/letsencrypt, so /etc/letsencrypt.sh was used. I agree that a directory name with a .sh extension is unusual, but I think in this case it's needed.
-
Hi DanB35,
When I installed in 2016-06-26 the directory was still /etc/letsencrypt.sh.
But soon, everything will change:
(May 12, 2016) Announcing Certbot: EFF's Client for Let's Encrypt -- https://www.eff.org/fr/deeplinks/2016/05/announcing-certbot-new-tls-robot
... Certbot is the next iteration of the Let's Encrypt Client...
... Along with the rename, we've also launched a brand new website for Certbot...
... but by far the biggest feature of the website is an interactive instruction tool...
https://github.com/certbot/certbot
...Certbot, previously the Let's Encrypt Client, is EFF's tool to obtain certs from Let's Encrypt...
... You can also tell it exactly what you want it to do from the command line...
All of our documentations will be absolete. :-(
We just wait and Let's see what will happen, 8-)
Michel-André
-
The only part of our documentation that would be obsolete is what I removed over the weekend; letsencrypt.sh hasn't changed. I can't speak for what its developer might do in the future wrt directory names, of course.
-
Unfortunately as the RPM is not in contribs you cannot open a bug against it.... :-)
time to upload your code, isn't it? ;-)
-
time to upload your code, isn't it? ;-)
Not my choice.... and I can't really do it.... well, I can as I have access, but no idea how to :-)
I also believe JPP is going to work on a proper implementation over the next few months so it may be better to hang on for that - mine was only ever a temporary hack !
-
mmhh..
open a NFR and attach your srpm file, it'd be enough :-)
-
There's been a NFR for letsencrypt for a long time..... SRPM are on my repo....
-
I indeed plan to work on apache, letsencrypt and multiple ceryificat in the next months on SME 10. This might be a candidate for backport on sme 9. I need to first finish the work i started on ibays.
-
This might be a candidate for backport on sme 9. I need to first finish the work i started on ibays.
This is not the good place to debate, but I'm not sure that sme9 worth it...We need to improve and add functionalities to sme10, but we must have a technology gap between the two product to force users to install sme10
-
+1
-
We need to improve and add functionalities to sme10, but we must have a technology gap between the two product to force users to install sme10
I don't think we need to force users to do anything :-)
-
I'll be one of the last... systemd nonsense.... yuck yuck yuck !
-
I'll be one of the last... systemd nonsense.... yuck yuck yuck !
Repeat after me....I love systemd !!! it is a therapy :)
-
Repeat after me....I love systemd !!! it is a therapy :)
:lol: Keep taking the tablets !
-
In any case I agree with stephdl: new features only on new releases
-
Hi all,
I noticed that wiht the --help, there is a new parameter:
--out (-o) certs/directory Output certificates into the specified directory
Michel-André