Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: DanB35 on September 29, 2015, 10:38:03 PM
-
I've been running SME Server, strictly as a home server, for the last 15 years or more. I've been using self-signed SSL/TLS certificates for this time, and so far it's been working OK. But as security measures advance, it's getting harder to convince modern browsers to accept self-generated certificates as valid. I heard a while back of letsencrypt.org, an EFF-sponsored project to issue free TLS certificates with domain validation only, which is planning to go live later this fall. This isn't the only source of free certificates, but it's my understanding that other places' certs aren't accepted by default by most browsers--Let's Encrypt has that as one of their major goals.
Part of their system is a script that reads the apache config, submits the CSR, validates control over the domain (or at least over the web server), and installs the certificate. I expect that making this work with SME server would take some doing, but even without it, it sounds like it has the potential to be a big win.
There's a pretty informative presentation about it at https://www.youtube.com/watch?v=OZyXx8Ie4pA
-
http://bugs.contribs.org/show_bug.cgi?id=8676
feel free to jump into ;-)
-
I shouldn't be surprised that someone's already on this, at least to the point of being interested. How can I, as a non-coder, help? It seems that testing would require something directly exposed to the 'net.
Poking around a bit more at their site, it looks like their utility also automates certificate renewal, and configuring your web server for a reasonable degree of security. Seems a bit of jiggery-pokery with the config db should be able to integrate this adequately...
-
Meanwhile StartSSL class 1 is completely free and accepted by every client :)
-
Good point. I'd seen StartSSL before, but had forgotten about them. They're available now, too, while Let's Encrypt is forecasting next month. I certainly wouldn't call them vaporware at this point, but that doesn't change the fact that they're not available today. However, StartSSL doesn't support multiple domains on their free certificates, which would make them a no-go for me.
As I think about it, though, I'm thinking that "free certificates" is among the less-remarkable features here. Perhaps more remarkable is how their tool automates the process--it parses your httpd.conf to determine what domains you have running, generates the private key locally, generates the CSR, makes the request, validates domain control, receives the issued certificate, installs it, and configures your web server to use it. All of this takes about a minute. It also automatically handles renewals of that certificate, and they support revocation as well, which StartSSL doesn't.
In short, they want to see HTTPS replace HTTP as broadly as possible, and they seem to be trying to make it as simple as possible for server admins to make that happen.
SME has the configuration template system, so the configuration changes made by the tool wouldn't stick (and might not even work at all). But the tool also has the ability to create the certs without making the server config changes. I'd think that doing that, and setting the appropriate config keys to the location of the new key and cert, would be a suitable 80-90% solution (and shouldn't require any development on SME server at all). The 100% solution would be to have a button or checkbox in the server manager to "Generate SSL Certificates" that would run the whole process, but of course that would take a bit of work on our end.
-
https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html (https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html)
We’re pleased to announce that we’ve received cross-signatures from IdenTrust, which means that our certificates are now trusted by all major browsers. This is a significant milestone since it means that visitors to websites using Let’s Encrypt certificates can enjoy a secure browsing experience with no special configuration required.
Both Let’s Encrypt intermediate certificates, Let’s Encrypt Authority X1 and Let’s Encrypt Authority X2, received cross-signatures. Web servers will need to be configured to serve the appropriate cross-signature certificate as part of the trust chain. The Let’s Encrypt client will handle this automatically.
You can see an example of a server using a Let’s Encrypt certificate under a new cross-signed intermedate here.
Vital personal and business information is flowing over the Internet more frequently than ever, and it’s time to encrypt all of it. That’s why we created Let’s Encrypt, and we’re excited to be one big step closer to bringing secure connections to every corner of the Web.
-
I will also like to do some testing with this if needed by a developer!
-
Looks like they're pushing back their release schedule a little bit. They'd previously project public release this week. They're now saying they'll enter "public beta" on 3 Dec, issuing valid signed certificates at that time. https://letsencrypt.org/2015/11/12/public-beta-timing.html
-
ATM it seems that centos6 (i.e. SME9) is unsupported because of its python version (2.6,)
anyway, using python from Software collection makes it work.
-
Hi
The public beta is now available.
As chance would have it, I had a fresh test install on my desk so I tried ssh as root then:
mkdir src
cd src
git clone https://github.com/letsencrypt/letsencrypt.git
cd letsencrypt
./letsencrypt-auto --apache -d your.domain.here
which failed to complete
I had a quick look in letsencrypt-auto which seems configurable for different setups, but the fine points are beyond me.
Thoughts anyone?
-
you'd really post here some logs/output to help us to understand what's wrong..
please be aware that SME9 has python 2.6 onboard which was not supported by letsencrypt
-
The first run reported:
Installed:
augeas-libs.x86_64 0:1.0.0-10.el6
gcc.x86_64 0:4.4.7-16.el6
libffi-devel.x86_64 0:3.0.5-3.2.el6
openssl-devel.x86_64 0:1.0.1e-42.el6
redhat-rpm-config.noarch 0:9.0.3-44.el6.centos
Dependency Installed:
cloog-ppl.x86_64 0:0.15.7-1.2.el6 cpp.x86_64 0:4.4.7-16.el6
keyutils-libs-devel.x86_64 0:1.4-5.el6 krb5-devel.x86_64 0:1.10.3-42.el6
libcom_err-devel.x86_64 0:1.41.12-22.el6 libgomp.x86_64 0:4.4.7-16.el6
libselinux-devel.x86_64 0:2.0.94-5.8.el6 libsepol-devel.x86_64 0:2.0.41-4.el6
mpfr.x86_64 0:2.4.1-6.el6 ppl.x86_64 0:0.10.2-11.el6
zlib-devel.x86_64 0:1.2.3-29.el6
Updated:
ca-certificates.noarch 0:2015.2.4-65.0.1.el6_6
Dependency Updated:
e2fsprogs.x86_64 0:1.41.12-22.el6
e2fsprogs-libs.x86_64 0:1.41.12-22.el6
keyutils.x86_64 0:1.4-5.el6
keyutils-libs.x86_64 0:1.4-5.el6
krb5-libs.x86_64 0:1.10.3-42.el6
libcom_err.x86_64 0:1.41.12-22.el6
libgcc.x86_64 0:4.4.7-16.el6
libselinux.x86_64 0:2.0.94-5.8.el6
libselinux-utils.x86_64 0:2.0.94-5.8.el6
libss.x86_64 0:1.41.12-22.el6
openssl.x86_64 0:1.0.1e-42.el6
Complete!
WARNING: Python 2.6 support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!
I was expecting the script to ask a few configuration questions, but it didn't
On re running with debug it looked at what it may need to install then reported:
Nothing to do
Creating virtual environment...
./letsencrypt-auto: line 166: virtualenv: command not found
Thanks
Kevin
-
first of all, I hope this is your test/play tool SME, not your production one..
about your issue: use Google (https://www.google.it/?q=.%2Fletsencrypt-auto%3A+line+166%3A+virtualenv%3A+command+not+found) to find the reasons and the solution.. it seems that you're not the first ;-)
-
Thanks Stefano
I was stupidly assuming that this was an SME specific issue, not a more general problem, and with SME in the search it didn't find anything helpful.
If, no when, I get it sorted I'll post a summary ...
(Yes definitely a test box)
-
Thanks Stefano
I was stupidly assuming that this was an SME specific issue, not a more general problem, and with SME in the search it didn't find anything helpful.
If, no when, I get it sorted I'll post a summary ...
(Yes definitely a test box)
you are welcome :-)
BTW, SME9 comes from Centos6.x, so be aware that the search base (and resultsets) is "a little" wider :-)
-
Getting there slowly (I hope) :-)
After installing Python2.7 and pip for instructions at http://wiki.contribs.org/Python_Altinstall
It progresses to:
The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError()
It seems the --apache looks for a debian install, though it appears possible to set the following paths:
--apache-ctl APACHE_CTL
--apache-enmod APACHE_ENMOD
--apache-dismod APACHE_DISMOD
--apache-le-vhost-ext APACHE_LE_VHOST_EXT
--apache-server-root APACHE_SERVER_ROOT
I have set --apache-server-root /etc/httpd --apache-ctl /usr/sbin/apachectl --apache-dismod /usr/bin/sedismod but am struggling to find any more to set.
I am still getting the no installation error
Thanks
-
I thought I read in their docs yesterday that the apache plugin requires apache 2.4, while CentOS 6 (and thus SME 9) uses 2.2. Even so, with the config file templating that SME does, I don't think you'd want to have the letsencrypt client make the config changes to use the new certs. What should work (I think), once the cert is generated, is to do
config setprop modSSL crt /path/to/crt
config setprop modSSL key /path/to/key
signal-event post-upgrade
signal-event reboot
...and the cert and key are in /etc/letsencrypt somewhere.
-
Getting there slowly (I hope) :-)
After installing Python2.7 and pip for instructions at http://wiki.contribs.org/Python_Altinstall
It progresses to:
The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError()
It seems the --apache looks for a debian install, though it appears possible to set the following paths:
--apache-ctl APACHE_CTL
--apache-enmod APACHE_ENMOD
--apache-dismod APACHE_DISMOD
--apache-le-vhost-ext APACHE_LE_VHOST_EXT
--apache-server-root APACHE_SERVER_ROOT
I have set --apache-server-root /etc/httpd --apache-ctl /usr/sbin/apachectl --apache-dismod /usr/bin/sedismod but am struggling to find any more to set.
I am still getting the no installation error
Thanks
please, don't mess with apache.. I mean: SME is not a plain Centos and so it differs a bit from Centos.
that said, your best bet is to use letsencrypt just like this example:
/letsencrypt-auto certonly --standalone --email admin@thing.com -d thing.com -d www.thing.com
then install your certificate (search the wiki, you'll find many usefull hints)
-
then install your certificate (search the wiki, you'll find many usefull hints)
Question about installing the certificate. The wiki at http://wiki.contribs.org/Custom_CA_Certificate#configuring_your_sme_with_your_new_certificate says to copy the cert and key to /home/e-smith/ssl.crt/ and /home/e-smith/ssl.key/, respectively. The letsencrypt client puts them somewhere in /etc/letsencrypt. Although it doesn't sound like this part is functioning yet, it's the goal of the letsencrypt folks to automate cert renewals as well, which would likely work best if the cert and key stay where the letsencrypt client puts them.
Since the config db entries call for a full pathname anyway, is there any reason that the cert and key need to be in /home/e-smith/? Or, put differently, is there any reason not to leave them in /etc/letsencrypt/? The only issue I can think of is that /etc/letsencrypt/ isn't backed up by the standard SME backup mechanisms, but it's easy enough to add a db entry to do so.
-
...just about there ...
Thanks guys
I have got it to: Error: The client lacks sufficient authorization
Which I guess is because this test box isn't accessible from the outside world. With hindsight this would seem a realistic prerequisite!
I'll create a public dns entry for it and route to it now and then test again.
-
thank you
please, report here all you can, letsencrypt's stuff sounds very interesting. :-)
-
Question about installing the certificate. The wiki at http://wiki.contribs.org/Custom_CA_Certificate#configuring_your_sme_with_your_new_certificate says to copy the cert and key to /home/e-smith/ssl.crt/ and /home/e-smith/ssl.key/, respectively. The letsencrypt client puts them somewhere in /etc/letsencrypt. Although it doesn't sound like this part is functioning yet, it's the goal of the letsencrypt folks to automate cert renewals as well, which would likely work best if the cert and key stay where the letsencrypt client puts them.
Since the config db entries call for a full pathname anyway, is there any reason that the cert and key need to be in /home/e-smith/? Or, put differently, is there any reason not to leave them in /etc/letsencrypt/? The only issue I can think of is that /etc/letsencrypt/ isn't backed up by the standard SME backup mechanisms, but it's easy enough to add a db entry to do so.
ATM, AFAIK, the big show stoppers about letsencrypt on SME are:
1) it needs python2.7 and even if we can use scl to install another python version, this is not easy as 1,2,3..
2) there's no available rpms, and so we need to download/install it via git
3) it is still in beta
once it will be released as stable, I'm quite sure that rpms will be available (I saw some NFR on RH's bugzilla about it).. then we could think about how to make it work in SME.. there will be likely a smeserver-letsencrypt rpm that will bring all the needed templates/fragments to make it usable in the easiest and safest way (as usual, I'd add ;-) )
-
1) it needs python2.7 and even if we can use scl to install another python version, this is not easy as 1,2,3..
2) there's no available rpms, and so we need to download/install it via git
3) it is still in beta
Understood on all counts. So, with that said, to my previous question--do the cert and key need to be in /home/e-smith/, or can they be in an arbitrary other location with the correct path fed to the config database? And other than that other location not being included in the default backup set (which can be controlled with its own config db entry), is there any reason to prefer one over the other?
-
One it was available on the internet the program ran (once I had stopped httpd)
It has created files
cert.pem
chain.pem
fullchain.pem
privkey.pem
It returned a message along the lines of your certificate is available at ..../fullchain.pem
So I typed
config setprop modSSL crt /path/to/fullchain.pem
config setprop modSSL key /path/to/fullchain.pem
signal-event post-upgrade
signal-event reboot
The box stopped serving web pages
Replacing fullchain, with cert.pem and privkey.pem and rerunning the above, now serves web pages but firefox still reports this page is not trusted ...
Are cert and privkey the correct certificates? Any ideas?
-
The plot thickens
The certificate has been saved OK but firefox does not recognise it:
See attached
-
On further examination, Chrome 47.0 and ie11 seem OK!
Firefox version 42.0.
Time to ask Let's Encrypt I feel.
When I have everything running OK I'll post the entire recipe.
-
I have found a post that suggests I should edit the apache ssl.conf file and insert a pointer to an SSLCertificateChainFile
I have got the chain file.
I cannot find anything on contribs.org to suggest where to put this
I guess somewhere like setpro modssl.
Is it as simple as
config setprop modSSL SSLCertificateChainFile /etc/letsencrypt/rest of file location/
Thanks
-
http://wiki.contribs.org/Certificates_Concepts#Custom_Certificate
-
The box stopped serving web pages
Replacing fullchain, with cert.pem and privkey.pem and rerunning the above, now serves web pages but firefox still reports this page is not trusted ...
Are cert and privkey the correct certificates? Any ideas?
yes.. time to dig into log files :-)
moreover, please post all your relevant steps in bugzilla too (bug reference is above), thank you
-
http://wiki.contribs.org/Certificates_Concepts#Custom_Certificate
That is just what I need.
I can't ssh from here so will look in the morning.
Thanks again
-
After installing Python2.7 and pip for instructions at http://wiki.contribs.org/Python_Altinstall (http://wiki.contribs.org/Python_Altinstall)
The recommended way to install a different version of Python is via Software collections.
Please see http://wiki.contribs.org/Software_Collections and the python related wiki page specifically.
-
The good news is that everything is now working.
However it feels like a bit of a fudge, and I'm not totally sure what has been done.
I will write up everything I have done in a couple of hours, after I have caught up with the work that has been neglected in the last couple of days.
In the mean time:
The problem seems to have been a missing certificate chain file
A test at https://whatsmychaincert.com gave an option to create the correct file, copying this to the server as chain.crt and then
config setprop modSSL CertificateChainFile /etc/letsencrypt/live/mydomain/chain.crt
signal-event post-upgrade; signal-event reboot
seems to have everything working across all browsers (all tested so far anyway!)
Thanks again everyone.
-
UPDATE
Not sure why I failed to try this earlier. You do not need to get a certificate from whatsmychaincert.com
Just add
config setprop modSSL CertificateChainFile /etc/letsencrypt/live/test.mydomain.co.uk/fullchain.pem
Now it can all be updated by a cron job running letsencrypt every once in a while.
It also works for multiple domains with extra -d options in lets encrypt.
-
FULL WORKING SOLUTION
NB Let's Encrypt is a public beta so things might change
Prerequisite: You will need Python 2.7 and pip
I followed instructions at http://wiki.contribs.org/Python_Altinstall
But am told I should have followed instructions at http://wiki.contribs.org/Software_Collections and the python related wiki page specifically.
Let's Encrypt needs virtualenv so:
pip install virtualenv
To use Let's Encrypt run:
mkdir src
cd src
git clone https://github.com/letsencrypt/letsencrypt.git
cd letsencrypt
service httpd-e-smith stop
./letsencrypt-auto certonly --standalone --email me@mydomain.co.uk -d test.firstdomain.co.uk -d seconddomain.co.uk -d www.seconddomain.co.uk
Replacing email and domains as required. Then configure SME with the certificates generated:
config setprop modSSL crt /etc/letsencrypt/live/test.firstdomain.co.uk/fullchain.pem
config setprop modSSL key /etc/letsencrypt/live/test.firstdomain.co.uk/privkey.pem
config setprop modSSL CertificateChainFile /etc/letsencrypt/live/test.firstdomain.co.uk/fullchain.pem
signal-event post-upgrade; signal-event reboot
There was a suggestion earlier in the forum thread that these certificates should be copied to a different location, but I used the default letsencrypt locations as above.
You can test your setup at https://whatsmychaincert.com
Thanks again to everyone on the forum for all the help. I could not have done it without you guys.
Kevin
-
@KevinG you should start to write a wiki page with the solution of the software collection...or at least with Python_Altinstall...thank in advance
-
Agreed on the wiki page.
I'm having trouble with the python27 repo, though--has something changed?
[root@sme-test ~]# yum list available \* --disablerepo=* --enablerepo=scl-python27
Loaded plugins: fastestmirror, smeserver
Loading mirror speeds from cached hostfile
https://www.softwarecollections.org/repos/rhscl/python27/epel-6-x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: scl-python27. Please verify its path and try again
[root@sme-test ~]# db yum_repositories show scl-python27
scl-python27=repository
BaseURL=https://www.softwarecollections.org/repos/rhscl/python27/epel-6-x86_64/
EnableGroups=no
Name=Software collections - python27
Visible=yes
status=disabled
[root@sme-test ~]#
-
Stephdl: No worries on the Wiki. Assuming it is reasonably straight forward.
Perhaps DanB35 can add something re software collections once he has a handle on it?
Kevin
-
I already made a placeholder wiki page: letsencrypt
-
I populate the wiki place holder with parts of this thread.
In the installation section i add :
add the 2.7 scl-repository by following : http://wiki.contribs.org/Scl#tab=Python27
Then : yum install python27 --enablerepo=scl-python27
at this time : scl enable python27 bash
And add a simple way to renew :
#!/bin/bash
source /opt/rh/python27/enable
export X_SCLS="`scl enable python27 'echo $X_SCLS'`"
service httpd-e-smith stop
cd /src/letsencrypt
./letsencrypt-auto certonly --standalone --email me@mydomain.co.uk -d test.firstdomain.co.uk -d seconddomain.co.uk -d www.seconddomain.co.uk --renew-by-default
service httpd-e-smith start
-
Thanks flep.
@others, please provide your feedback (Success, failure and errors)
-
Following the procedure now in the wiki (I made a few edits), it worked perfectly for me. ssllabs.com test shows the new cert and chain, and rates my server as A-. The renewal script also runs without issues, and without requiring any input.
Edit: The letsencrypt client docs say that the EPEL repository must be enabled for CentOS6. I did not find this to be the case. Although I have that repo installed on my server, it is disabled, and I did not enable it when I ran letsencrypt-auto.
So the next matter is setting up the automatic renewal. RequestedDeletion linked to the cron manager contrib, which I wasn't aware of, and which would make editing cron jobs a bit easier, but I don't see any way with that to set a job to run every other month, which would be plenty frequent for certificate renewal. I'd think the cron entry for root should look something like
48 22 3 */2 * /opt/letsencrypt-renew.sh
where letsencrypt-renew.sh is the script that flep posted. This is set to run at 22:48 on the third of every other month (Feb, Apr, Jun, etc.), which will renew the cert well before it expires in 90 days. I've chosen that time of day because my daily backup runs at 23:00, so this would make sure the new cert is in that day's backup rather than waiting until the next day's; you'd obviously want to adjust as appropriate for your installation. The third is a randomly-chosen date.
-
...although as I think about it for another minute or two, it seems the renewal script should have a signal-event email-update in it too, to restart the email services that also use the SSL certificates. Thoughts?
-
and a ibay-modify event too, so that even httpd is restarted.. IMO there's no an event like email-update for http
-
The signal-event command doesn't support multiple arguments, does it? Like signal-event domain-modify ibay-modify email-update?
-
The signal-event command doesn't support multiple arguments, does it? Like signal-event domain-modify ibay-modify email-update?
no, each signal-event must be a single command.. (BTW, for example, ibay-modify can accept the ibay name as an argument)
-
Makes sense. I've edited the script in the wiki to run all three events.
-
AFAIK, signal-event email-update is not enough, because it simply reload qpsmtpd/sqpsmtpd, and does not restart them. We should create a new ssl-update event, which can restart needed services (and any contrib author using the SSL cert could hook into it)
Please open an NFR for this
-
Done. http://bugs.contribs.org/show_bug.cgi?id=9152
-
So the next matter is setting up the automatic renewal. RequestedDeletion linked to the cron manager contrib, which I wasn't aware of, and which would make editing cron jobs a bit easier, but I don't see any way with that to set a job to run every other month, which would be plenty frequent for certificate renewal. I'd think the cron entry for root should look something like
48 22 3 */2 * /opt/letsencrypt-renew.sh
In a template-driven distro editing cron shoud be done like in http://wiki.contribs.org/Cron_entry
I edit the wiki according to.
-
I hadn't known (or at least remembered) that crontab was templated. Good call to add that.
-
Good calls guys. @others reading this, please test and provide your feedback and/or suggestions.
-
It broke my server. HTTPD is started but web pages no longer display. Not even when I use the IP address...
-
root@server letsencrypt]# ./letsencrypt-auto certonly --standalone --email adam@livingnatural.com.au -d livingnatural.com.au
Updating letsencrypt and virtual environment dependencies.......
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly --standalone --email adam@livingnatural.com.au -d livingnatural.com.au
Version: 1.1-20080819
Version: 1.1-20080819
Failed authorization procedure. livingnatural.com.au (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client for DV :: DNS query timed out
IMPORTANT NOTES:
- The following 'urn:acme:error:connection' errors were reported by
the server:
Domains: livingnatural.com.au
Error: The server could not connect to the client for DV
Any thoughts on why my web server no longer works at all??
-
The script runs
service httpd-e-smith stop
If it stopped you will need a
service httpd-e-smith start
The error occurred for me when I did not have my test server exposed to the internet and correctly on a public dns. Check that first.
Good luck
-
service httpd-e-smith was restarted.. I even restarted the server, but to no avail..
Fortunately I took a snapshot of the server before making the change, and have now rolled back.
Not keen to try again until I figure out what went wrong.
-
well, you'd take a look at the logs..
-
Did you stop when you got the error or did you continue and try the following lines?:
config setprop modSSL crt /etc/letsencrypt/live/test.firstdomain.co.uk/cert.pem
config setprop modSSL key /etc/letsencrypt/live/test.firstdomain.co.uk/privkey.pem
config setprop modSSL CertificateChainFile /etc/letsencrypt/live/test.firstdomain.co.uk/fullchain.pem
signal-event domain-modify; signal-event email-update
Setting those properties without the certificates will kill off https service quite well.
You can use config delprop to remove settings you don't want.
-
I did continue with the error.. Now I know what went wrong..
Thank you very much..
I will try again soon.
-
root@server letsencrypt]# ./letsencrypt-auto certonly --standalone --email adam@livingnatural.com.au -d livingnatural.com.au
Updating letsencrypt and virtual environment dependencies.......
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly --standalone --email adam@livingnatural.com.au -d livingnatural.com.au
Version: 1.1-20080819
Version: 1.1-20080819
Failed authorization procedure. livingnatural.com.au (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client for DV :: DNS query timed out
IMPORTANT NOTES:
- The following 'urn:acme:error:connection' errors were reported by
the server:
Domains: livingnatural.com.au
Error: The server could not connect to the client for DV
Any thoughts on why my web server no longer works at all??
both ports 80 and 433 must be opened or forward, if you use virtual machine or proxy please check config.
-
Maybe we need to add to the wiki page that server-gateway mode is the only supported mode? We need to add something about this for there any many exotic port forwarded masquerading setups out there.
Thoughts?
-
Why are you suggesting server only mode is not supported?
The first test box I set up was server only and worked fine.
Am I missing something?
Ah, I think if it was behind a NAT router you would have problems, but if it is straight on a public IP it is fine. So we probably need a note about NAT, or a recommendation to setup and renew with direct connection?
Once you have the certificates they seem to work ok through the NAT (I can double check at the office tomorrow)
Apologies that this is a bit of a ramble.
Kevin
-
Maybe we need to add to the wiki page that server-gateway mode is the only supported mode?
Since this isn't really "supported" at all (it isn't even a contrib yet, much less part of the official distro), and SSL certificates certainly ought to work in sever-only mode, I wouldn't think a note like this would really be appropriate. I've added a statement to the prerequisites that port 80 must be open to the outside (I don't believe it's the case that both ports 80 and 443 need to be open for the client to run, but obviously 443 needs to be open for the normal use of the certificate), which I'd think would really be adequate.
-
Good enough for me :-)
psss, did you know that SME Server 9.1 just got released....
-
psss, did you know that SME Server 9.1 just got released....
Nope, there's no release announcement here in the forums, and I don't visit the contribs.org home page that often. Can I upgrade from 9.0 using yum, or do I need to download the ISO, down the server, boot from the ISO, and do an upgrade that way?
-
And there was me thinking I'd get a break from SME for a bit tomorrow :wink:
-
Nope, there's no release announcement here in the forums, and I don't visit the contribs.org home page that often. Can I upgrade from 9.0 using yum, or do I need to download the ISO, down the server, boot from the ISO, and do an upgrade that way?
It's just hitting the mirrors for the next 48 hours. Yum will do the trick.
-
Great! I assume release notes will be posted shortly?
-
It's not on the UK mirror, but have downloaded from
http://sme-mirror.firewall-services.com/releases/9.1/iso/x86_64/
-
Great! I assume release notes will be posted shortly?
Announcement and release notes will follow shortly. After all mirrors have been synced. just gave a heads up on what's coming...
-
My issue is that I continued to create the certificates after i got an error message from Letsencrypt. This killed my web server.. My server is setup in "server only" mode and I have all the right ports forwarded through the firewall. Are you saying that Server only mode wont work? Why not?
-
What's the error please? What do the logs say, what did you see?
-
My issue is that I continued to create the certificates after i got an error message from Letsencrypt.
What I think you did wasn't to create the certificates (it's the letsencrypt client and server that do that), but instead to set config database entries pointing to a certificate, chain, and key that didn't exist. That would most definitely kill your web server.
The error message given by the client indicates that the letsencrypt server wasn't able to resolve livingnatural.com.au. I don't know why that would be; I'm able to resolve it to 139.218.184.183.
I'd suggest trying again. Do
# cd /opt/letsencrypt
# service httpd-e-smith stop
# scl enable python27
# ./letsencrypt-auto certonly --standalone --email adam@livingnatural.com.au -d livingnatural.com.au
# service httpd-e-smith start
...and stop there, and post the output here. This should be safe to run, as it won't change any of your server configuration. Also post the output of 'ls -l /etc/letsencrypt/live/livingnatural.com.au/'
BTW, do you want more than one host name on the certificate? If I browse to livingnatural.com.au, I'm automatically redirected to www.livingnatural.com.au; wouldn't you want the www. hostname on the certificate as well? If so, that's easy to do; just add "-d www.livingnatural.com.au" to the end of the letsencrypt-auto command.
-
My server runs as a VM on Proxmox. Before installing Letsencrypt i took a snapshot.. I have since restored to the working version. I did take a post implementation snapshot with the broken config. When I get a chance i may restore to a new VM. but I suspect it may be quicker to snapshot again and start the letsencrypt install from scratch.
-
I'd suggest installing letsencrypt (which requires as prerequisites only installing scl-utils and python27 from the scl-python27 repository), and then taking a snapshot before running it. Your server at that point should be in an entirely safe and consistent state. Then try what I suggested above.
-
Adam
If letsencrypt gets as far as a can't resolve error then python etc is all in place OK and you have to be looking at a connectivity issue of some sort. I had the same error on a test box until I made it public facing.
I shall experiment with port forwarding through a NAT if I get a moment later (unless anyone else can report their experiences)
-
I just massively failed installing Letsencrypt. Followed the wiki page to the letter, but it died on me running the Letencrypt command and then it tries to resolve dependencies such as Python-devel...
Just a quick note, will dive into it later.
-
On 9 or 9.1?
I shall try installing on 9.1 later if the day job doesn't get in the way!
-
My failure started with 9.0 updated, but remained with updated to 9.1. Why is it pulling Python dev?
-
My failure started with 9.0 updated, but remained with updated to 9.1. Why is it pulling Python dev?
i add a rollback section in wiki:
http://wiki.contribs.org/Letsencrypt#Troubleshooting
-
I have just successfully run letsencrypt from behind a NAT firewall with no problems.
Interestingly it pulled up rpm-check-debug which I hadn't noticed before and rattled off checking things for a while.
Also since I first ran letsencrypt the first few times someone has added "exit" to the end of the section headed "To use Let's Encrypt run: ". I'm not sure why, or what effect it might have, but would speculate that it could be terminating something prematurely. I ran without it on the install above.
While that was running I have managed an install of 9.1 on a test box. Will try that shortly ...
-
And all is well with a straight wiki install (excluding "exit" after the ./letsencrypt-auto line) on a clean install of 9.1.
Thinking back, I think all the installs have done the rpm-check, but the box behind the NAT firewall had more installed on it so the check took longer.
-
And all is well with a straight wiki install (excluding "exit" after the ./letsencrypt-auto line) on a clean install of 9.1.
the "exit" command is needed to exit the scl bash session.. it'd be harmless, but necessary
-
OK. No worries.
There is a typo on the wiki. How do I get a logon to correct it? My forum logon does not seem to work.
-
OK. No worries.
There is a typo on the wiki. How do I get a logon to correct it? My forum logon does not seem to work.
you find it in the wiki :-D
http://wiki.contribs.org/Help:Contents#How_to_get_a_wiki_account.3F
-
@RequestedDeletion, surprised you saw that kind of failure. I just tried it on a fresh 9.1 test VM, and it's working fine. Notably, this VM doesn't have the EPEL repo configured at all--the letsencrypt client docs say it needs to be enabled for CentOS 6, and it's present (though disabled) on my main server. I wondered if the letsencrypt-auto script might have enabled it anyway, but that does not appear to have been the case. The only repo added was scl-python27, and the only packages added to the base install (before running letsencrypt-auto) were scl-utils and python27 (plus whatever dependencies it pulled in with it).
-
@Dan, I was surprised too. First I thought it may come from downloading the github zip file, but after quickly trying the git pull, I experienced the same. I need to free some more time to see what is happening on *my* server.
-
...and FWIW, for this last test, I downloaded the zip file as well. My wild speculation would be that you're using different mirrors for your repos than I am.
-
After installing Python2.7 and pip for instructions at http://wiki.contribs.org/Python_Altinstall
letsencrypt now claims to support python 2.6, so those steps are now an unnecessary complication.
-
...except that running under Python 2.6 gives this output:
[root@e-smith letsencrypt]# ./letsencrypt-auto
WARNING: Python 2.6 support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!
Probably should try it out though...
-
Note also that Red Hat/EPEL have started work on integration:
https://bugzilla.redhat.com/show_bug.cgi?id=1288744
-
Noted, and certainly once they release an RPM into EPEL that will be a better way to go.
When I try running the letsencrypt client with Python 2.6, it dies due to the lack of virtualenv.
Edit: If I add and enable the EPEL repo (set status enabled, signal-event yum-modify), the letsencrypt client runs and gets a certificate.
-
The instruction to run it was in about post 20 or so. :lol:
from memory
pip install virtualenv
-
...but that didn't make it into the wiki, and it isn't needed if we're running under Python 2.7. The Letsencrypt client docs say that CentOS 6 users need to have the EPEL repository enabled, but that doesn't seem to be the case either if we're using Python 2.7. But if using Python 2.6, it apparently is necessary either to manually install virtualenv (pip install virtualenv) or have the EPEL repo configured and enabled.
-
Should I upgrade to SME9.1 before or after upgrading?
Thanks
-
As far as I can tell, it doesn't make a difference.
-
I needed pip install virtualenv when I used the altinstall, but the need went away using the scl python27
-
letsencrypt now claims to support python 2.6, so those steps are now an unnecessary complication.
yes, sure, but searching with google about running it on a Centos 6.X leads me to say that no, it doesn't work.. :-)
the scl path works fine
once RH will release their rpm via the epel repo, we'd think about a contrib
-
Note also that Red Hat/EPEL have started work on integration:
https://bugzilla.redhat.com/show_bug.cgi?id=1288744 (https://bugzilla.redhat.com/show_bug.cgi?id=1288744)
I linked this bug (https://bugzilla.redhat.com/show_bug.cgi?id=1287193#c21) in our BZ (see #8676 (http://bugs.contribs.org/show_bug.cgi?id=8676))
-
@adamcyberspace,
There's some discussion on the letsencrypt forum about DNS problems; it might be relevant to your issue. https://community.letsencrypt.org/t/dns-query-timed-out/5353/23
-
There's a simpler client here:
https://github.com/kuba/simp_le
-
There are actually quite a lot of client implementations available:
https://community.letsencrypt.org/t/list-of-client-implementations/2103
They have different dependencies (one is even a bash script), and it looks like there are implementations in Perl, Bash, Ruby, PHP, Python, Java, pretty much anything interesting.
There's also https://gethttpsforfree.com/ for those who don't want to install anything on their servers. Renewal can't really be automated that way though. A somewhat prettier web-based system is at https://letsgetssl.com/.
-
my install worked fine for 2 X domains but could not get the www.livingnatural.com.au domain to work.
Not a huge deal at this point in time, but strange that the other domains worked and this did not.. the DNS is with a different provider and may be configured differently.. apart from that I cannot think what the issue might be.
-
@adam
Someone on the letsencrypt.org thread mentioned he's also having trouble with a host with DNS records at netregistry.net. There's an open issue (https://github.com/letsencrypt/letsencrypt/issues/1610), and the issue with netregistry is noted there as well, but I don't see any more information about what's going on or the cause.
Best advice I have is to follow the letsencrypt forums and the bug on github.
-
And for Python 2.7 this can help:
https://community.letsencrypt.org/t/redhat-centos-6-x-users-need-python-2-7/2190
(crossposted from BugZilla = 8676 http://bugs.contribs.org/show_bug.cgi?id=8676 )
-
And for Python 2.7 this can help:
https://community.letsencrypt.org/t/redhat-centos-6-x-users-need-python-2-7/2190 (https://community.letsencrypt.org/t/redhat-centos-6-x-users-need-python-2-7/2190)
(crossposted from BugZilla = 8676 http://bugs.contribs.org/show_bug.cgi?id=8676 (http://bugs.contribs.org/show_bug.cgi?id=8676) )
Please let's not clutter this thread with SCL vs IUS. You can open a new thread for that purpose.
-
After you referred him to this thread from BZ?
-
Yes, for SCL is the preferred way with SME Server atm, maybe he was not aware. Cross posting was not my advise.
-
Dear All
I just wonder whether all this effort to get "free" certificates is worth it.
There are certificates available from commercial suppliers/ISPs/Providers etc (eg Godaddy & others) for between $10 - $50.
That cost is far cheaper than the tech support hours spent on implementing the various methods being discussed in this thread & elsewhere in the forums.
I am not saying not to use these clever "free" tools, just that there are nowadays very cheap certificates available.
-
Janet,
As I see it, LE offers several advantages over other CAs. Here are some that come to mind:
- Certificates are free
- Certificates are trusted by most client apps (unlike cacert.org)
- Certificates can cover up to 100 hostnames/domains, unlike some low-cost/free CAs
- All private keys are generated locally, and never leave your server
- Revocation is also supported at no cost (unlike startssl.com)
- Certificates can be issued in under a minute from a single command line
- Certificates can be renewed automatically by a cron job
- The client is designed to automatically install certificates in a running web server, and configure that server to use the certificate and to serve HTTPS (exclusively, if desired). That feature isn't quite ready for prime time, and it wouldn't be very suitable for SME servers anyway, but it fits well with their goal of making it as easy as possible to bring trusted encryption to as many sites as possible
Of course, there are some limitations, which may or may not be drawbacks depending on your situation:
- Certificates are only valid for 90 days, rather than the 365 days that's more common with commercial CAs
- Wildcard certificates (i.e., *.yourdomain.tld) aren't supported
- Letsencrypt only performs domain validation--they only verify that the person requesting the certificate has control over the domain/host requested. They don't validate any other information about the requestor (so people won't see the green bar in their browsers, as they do for EV certificates)
- Features 6, 7, and 8 above require that the client be installed, which for best results apparently requires that Python 2.7 be installed. The client isn't yet available as an RPM, though RH have said it will be going into EPEL for CentOS6/RHEL6, and CentOS6 ships with Python 2.6. As of right now, that means a little more work in getting the client running.
Limitation #2 can, IMO, be addressed by including all the hostnames you want to use as SubjectAltNames, of which Letsencrypt supports up to 100 per certificate. There may well be applications which require a wildcard, but I'd expect they're fairly uncommon.
Limitation #4 can be mitigated by use of a different client, or even no client--you can get Letsencrypt certs without installing anything by going to https://letsgetssl.net/ or https://gethttpsforfree.com/. This process involves manually messing around with openssl at the command line, but most of this is what you'd have to do to get a cert from someone else anyway. But, of course, using one of these web-based options means you can't auto-renew. One of the other clients would still allow auto-renewal, but still might require more user interaction to get going in the first place.
But in the end, "all this effort" consists, today, of:
- yum install scl-utils
- yum --enablerepo=scl-python27 install python27
- Download and unpack a .zip file
- Stop httpd-e-smith
- Run one command
- Set the appropriate db keys to point to the new certificate files
- post-upgrade;reboot
With the release of the letsencrypt client into EPEL, the first three steps will be replaced with 'yum --enablerepo=epel install letsencrypt'. The last two steps will be required no matter where you get your cert.
-
I agree with Dan, and would like to add that it is the journey of the learning curve that is part of our enthusiasm for SME Server.
-
I agree with Dan, and would like to add that it is the journey of the learning curve that is part of our enthusiasm for SME Server.
I agree too, and this topic has been a good example of many people working together for a common aim..
tomorrow, when letsencrypt rpm will be available, we can create a contrib to integrate it with SME, and what has been discussed here could/will be a good start point (or, at least, a good brainstorming exercise)
-
The RPM is due out tomorrow? Excellent! I didn't expect it would be released so quickly.
-
The RPM is due out tomorrow? Excellent! I didn't expect it would be released so quickly.
no, you misunderstood me or I did not explain myself :-)
when I say "tomorrow", in my previuos post, I meant "in the future..."
I literally translated from italian to english, sorry :-)
-
Ah, ok, that makes sense too. We still have a working (or at least mostly-working) solution today.
-
Actually "Tomorrow" might be correct - Fedora has support now...
https://fedoramagazine.org/letsencrypt-now-available-fedora/
-
ROTFL.. :-D
I'd go to bet some bucks :-)
-
I have a few question about some of the wiki content that, in short, seems overly-cautious, or to show misplaced caution. Since it's a wiki, I could, of course, just edit it, but it's always possible I'm missing something. This seems like a better venue to discuss than the talk page on the wiki.
1. Under Prerequisites, there's discussion of noting, or backing up, the modSSL configuration. Then follows this: "or to be sure, a copy of the complete configuration database (a good practice before any action such as manual changing of db values or installing a contrib)".
Really? Are we really going to recommend that any time someone installs a contrib, or makes any manual change to the configuration database, that they make a complete backup copy of the database? This seems entirely unnecessary to me, particularly since any changes to the database are logged in /var/log/messages. Noting existing values (if any) of properties you're going to change, or even making a backup of those properties, would make sense. A backup of the entire config database, with hundreds of lines to dig through to find what you're looking for, just seems like overkill. I might feel differently on this if there were a way of doing a "config import" from the backup file (thus reverting the config database to the time the backup was made), but AFAIK there's no way to do that.
2. In the installation section are commands to set the modSSL properties for the cert, key, and chain file. Following those commands is this note:
We need to see if setting the above db variables disturbs other SME Server default functionality and contribs that work with certificates such as VPN solutions.
Those same db variable settings appear on the wiki in at least five other places (http://wiki.contribs.org/Custom_CA_Certificate, http://wiki.contribs.org/Certificate_Concepts, http://wiki.contribs.org/Certificate_Integration_GoDaddy_Certificate, http://wiki.contribs.org/Certificate_Integration_Thawte_Certificate, and http://wiki.contribs.org/Certificate_Integration_startssl.com_Server_Certificate), with no such warning. They appear to be the well-documented "SME way" to specify a certificate, key, and chain file. I can't see any reason why this warning needs to uniquely appear on the page for letsencrypt.
3. There's a note in the renewal section, partly about the script, and partly about software collections in general:
The above commands enable Python 2.7, but do not disable it again. In general we need to examine the effect of using SCL Python 2.7 on production servers where the default Python version is being used.
As to the first issue, I'd think that running the script properly (i.e., './letsencrypt-renew.sh' rather than 'source letsencrypt-renew.sh') would itself take care of disabling Python 2.7--it will spawn its own shell, and when the script exits, any environment changes it makes should go away, right? But another way to make sure that python27 is only enabled for that script would seem to be deleting lines 2 and 3 of the script, and calling the script with
scl enable python27 '/opt/letsencrypt-renew.sh'
As to "examin[ing] the effect of using SCL Python 2.7"--isn't that pretty much the point of using the software collections? To allow you to install a newer version of some software package, so that it can be used when required, but still doesn't interfere with the rest of the system unless explicitly called? If we aren't confident that they'll work in that way, it seems that should be noted on http://wiki.contribs.org/Software_Collections
-
I have a few question about some of the wiki content that, in short, seems overly-cautious, or to show misplaced caution. Since it's a wiki, I could, of course, just edit it, but it's always possible I'm missing something. This seems like a better venue to discuss than the talk page on the wiki.
I think that as you already know, SME is not a bleeding edge distro. It is known for simplicity and stability. There are of course lots of people who want to hack it about, which is fine, but as you can see from a lot of forum posts, a large percentage of issues are caused by people who just don't take sufficient care and then wonder why their server has backflipped into the lava.
Remember that most contribs are properly tested and verified before being let lose on an unsuspecting public.
As with any software that is still very much in 'testing' such as this, then the best thing we can do is put up big warning signs up so hopefully people will realise the damage they may do. Caution is no bad thing.... I am still amazed at how many people try stuff on their production boxes....
Quite honestly it doesn't take much to back up your databases, and when messing with stuff like this it is a very sensible precaution, unless you are trying it on a test server (which is a much better idea)
B. Rgds
John
-
1. Under Prerequisites, there's discussion of noting, or backing up, the modSSL configuration. Then follows this: "or to be sure, a copy of the complete configuration database (a good practice before any action such as manual changing of db values or installing a contrib)".
Really? Are we really going to recommend that any time someone installs a contrib, or makes any manual change to the configuration database, that they make a complete backup copy of the database? This seems entirely unnecessary to me, particularly since any changes to the database are logged in /var/log/messages. Noting existing values (if any) of properties you're going to change, or even making a backup of those properties, would make sense. A backup of the entire config database, with hundreds of lines to dig through to find what you're looking for, just seems like overkill. I might feel differently on this if there were a way of doing a "config import" from the backup file (thus reverting the config database to the time the backup was made), but AFAIK there's no way to do that.
I agree with ReetP and next to that, we must keep in mind that we have a very mixed audience with skill sets and understanding of SME Server at very different levels. Also we (I) like to write or adjust wiki articles so that they are 'easy' to read and informative about related aspects then just the specific article. I'll put in a NFR for automatic backup the db as part of certain events, storing them to /var/log/esmith/*
2. In the installation section are commands to set the modSSL properties for the cert, key, and chain file. Following those commands is this note:Those same db variable settings appear on the wiki in at least five other places (http://wiki.contribs.org/Custom_CA_Certificate (http://wiki.contribs.org/Custom_CA_Certificate), http://wiki.contribs.org/Certificate_Concepts (http://wiki.contribs.org/Certificate_Concepts), http://wiki.contribs.org/Certificate_Integration_GoDaddy_Certificate (http://wiki.contribs.org/Certificate_Integration_GoDaddy_Certificate), http://wiki.contribs.org/Certificate_Integration_Thawte_Certificate (http://wiki.contribs.org/Certificate_Integration_Thawte_Certificate), and http://wiki.contribs.org/Certificate_Integration_startssl.com_Server_Certificate (http://wiki.contribs.org/Certificate_Integration_startssl.com_Server_Certificate)), with no such warning. They appear to be the well-documented "SME way" to specify a certificate, key, and chain file. I can't see any reason why this warning needs to uniquely appear on the page for letsencrypt.
Agree. I'm not an expert on certificates at all, so that's why I wonder 'how about other mechanisms or contribs that use certificates if letsencrypt sets new names and locations of certificates, claiming full ownership. And yes I agree, this should aply to all wiki pages that handle certificates *IF* the thoughts are valid.
3. There's a note in the renewal section, partly about the script, and partly about software collections in general:
As to the first issue, I'd think that running the script properly (i.e., './letsencrypt-renew.sh' rather than 'source letsencrypt-renew.sh') would itself take care of disabling Python 2.7--it will spawn its own shell, and when the script exits, any environment changes it makes should go away, right? But another way to make sure that python27 is only enabled for that script would seem to be deleting lines 2 and 3 of the script, and calling the script with
scl enable python27 '/opt/letsencrypt-renew.sh'
As to "examin[ing] the effect of using SCL Python 2.7"--isn't that pretty much the point of using the software collections? To allow you to install a newer version of some software package, so that it can be used when required, but still doesn't interfere with the rest of the system unless explicitly called? If we aren't confident that they'll work in that way, it seems that should be noted on http://wiki.contribs.org/Software_Collections (http://wiki.contribs.org/Software_Collections)
SCL works, and the script(s) needs to be reviewed and consistent. Hence the wiki page is a WIP.
Thanks for the thoughts.
-
3. There's a note in the renewal section, partly about the script, and partly about software collections in general:
As to the first issue, I'd think that running the script properly (i.e., './letsencrypt-renew.sh' rather than 'source letsencrypt-renew.sh') would itself take care of disabling Python 2.7--it will spawn its own shell, and when the script exits, any environment changes it makes should go away, right? But another way to make sure that python27 is only enabled for that script would seem to be deleting lines 2 and 3 of the script, and calling the script with
scl enable python27 '/opt/letsencrypt-renew.sh'
I think that would be the correct approach. But *think* that the '\opt' directory of the Python 2.7 will be searched, and nothing will be found, for the script is in (root)/opt/ path, not /opt/rh/python27/opt (or something similar)...
-
I certainly understand that SME Server is not, and is not intended to be, a bleeding-edge distro--its focus is on stability (which it's built on CentOS/RHEL rather than Fedora or Ubuntu). I also understand the need for caution, especially when dealing with beta software. I don't have any issue with labeling the page as WIP, nor identifying the skill level as Advanced. My concern with at least two of the three points I raised was that they just seemed to be overly cautious, possibly bordering on FUD.
1. Database backup. I can see value in a text backup of the config keys you're altering. "config show modSSL > backup.txt" makes perfect sense. I can see value in a restore-able backup of the entire config database--if you manage to hose it, just revert to the backup. We don't have that (yet?). I just don't see the value in a text backup of the entire config database--you can't restore from it, so you have to manually look through it to find how things were before you changed them. If you're going to do that, you might as well grep through /var/log/messages and find the changes you've made. All the changes are logged there, so you can see whatever you've changed. IMO, if we're going to call something a best practice, it should give some specific benefit that we don't already have, and I'm just not seeing it here.
2. Note on the certificates. Is the concern here that the cert files are in /etc/letsencrypt rather than /home/e-smith/? I could understand that (I raised the question myself up-thread), though so far it doesn't seem to be a problem. Everything in /etc/letsencrypt is owned by root:root, as in /home/e-smith/ssl.key and /home/e-smith/ssl.crt. OTOH, those config properties clearly call for full paths, so any config file that's going to use them should be able to deal with a proper (i.e., PEM-encoded) cert or key wherever located. I think the LE-generated cert/key have already been demonstrated to work with the base install; if they somehow break a contrib, that would be a bug against the contrib. But I wouldn't have a problem with noting that the SSL key and certificate have traditionally been located in /home/e-smith, and it's not certain at this time whether placing them in /etc/letsencrypt instead would cause any problems.
3. On SCL. I know I use that approach for php56 in a cron job, and that works without issue. I just set up one with a test letsencrypt script (it just calls letsencrypt --help), and it does seem to work--letsencrypt-auto runs, and it doesn't give the Python 2.6 warning, so that indicates it is running in a Python 2.7 environment.
Edit: Just to be clear, my cron entry is:
38 9 18 12 * scl enable python27 '/opt/letsencrypt-test.sh'...and /opt/letsencrypt-test.sh is:
[root@e-smith opt]# cat letsencrypt-test.sh
#!/bin/bash
/opt/letsencrypt/letsencrypt-auto --help all
Since I know that letsencrypt-auto will error out if run under Python 2.6 without the --debug flag set, I figured this would be a valid test. It did run, and emailed me the help output.
-
I certainly understand that SME Server is not, and is not intended to be, a bleeding-edge distro--its focus is on stability (which it's built on CentOS/RHEL rather than Fedora or Ubuntu). I also understand the need for caution, especially when dealing with beta software. I don't have any issue with labeling the page as WIP, nor identifying the skill level as Advanced. My concern with at least two of the three points I raised was that they just seemed to be overly cautious, possibly bordering on FUD.
DanB35: every experienced user knows that every available contrib has been tested, and so there's no need to backup dbs or being worried..
anyway, we're here talking about a new feature.. a WIP.. letsencrypt seems to be very interesting and so many (un)experienced users may be attracted by it.. messing with certificats could lead to an unusable server.. while me, you and many others know how to deal with an unresponsive web server, a unexperienced user could say "ehi, damn, I broke my server.." (we already had some cases in this topic too.. ;-) )
there's no FUD here.. once we'll have a working contrib, we'll be sure everything to be safe, as usual..
I saw you spent much time to read all certificates related pages.. I'm sure that some of them could be outdated and/or that their content cpuld/should be improved or, at least, unified in some ways.. if so, please, feel free to edit where needed.. and, of course, thank you for your input and your effort..
SME is a good product ALSO because it has a good documentation.. the issue here is that wiki is huge, we are few and sometimes we just don't be aware that some pages are (too) old and must be updated.
-
Just a little word to thank you all for your work.
I followed these procedure : http://wiki.contribs.org/Letsencrypt
And it worked the first time, perfectly. I have now a free public certificate. It's awesome ! 8-)
I followed the method with letsencrypt.sh, it seems easier for me.
The wiki is very well done, thank about troubleshooting for the newbies on the subject.
-
And it worked the first time, perfectly. I have now a free public certificate. It's awesome ! 8-)
I followed the method with letsencrypt.sh, it seems easier for me.
Excellent! Yes, I think for our purposes that letsencrypt.sh is a simpler path than using the official client. John is working on an RPM that should simplify the process even further, and work equally well on SME8 and SME9. I'd still like to see it move into the base system, but this would be a big step in that direction.
-
Excellent! Yes, I think for our purposes that letsencrypt.sh is a simpler path than using the official client. John is working on an RPM that should simplify the process even further, and work equally well on SME8 and SME9. I'd still like to see it move into the base system, but this would be a big step in that direction.
Yes, please have a go at installing and testing the RPM. Best on a test machine, but we need feedback.
http://bugs.contribs.org/show_bug.cgi?id=8676
https://github.com/reetp/smeserver-letsencrypt/tree/smeserver-letsencrypt-0.1
-
Yes, please have a go at installing and testing the RPM. Best on a test machine, but we need feedback.
http://bugs.contribs.org/show_bug.cgi?id=8676
https://github.com/reetp/smeserver-letsencrypt/tree/smeserver-letsencrypt-0.1
Just to encourage les autres, I can confirm I've used John's RPM and ended up with working certs on three systems so far...
-
Installed letsencrypt.sh according to wiki 2 days ago. Today I see the following on running the letsencrypt.sh script. (followed wiki directives and testing daily cron job).
letsencrypt.sh -c
#
# !! WARNING !! No main config file found, using default config!
#
ERROR: WELLKNOWN directory doesn't exist, please create /usr/local/bin/.acme-challenges and set appropriate permissions.
-
What are the contents of /etc/letsencrypt.sh?
-
What are the contents of /etc/letsencrypt.sh?
There is no /etc/letsencrypt.sh
-
There is no /etc/letsencrypt.sh
Well, there's your problem. Why not? The git clone to download letsencrypt.sh should have been done from inside /etc/, and it should have created a subdirectory of letsencrypt.sh. Was that directory present at any time?
-
MY BAD!!!
Instead of using GIT, I downloaded and moved the letsencrypt.sh in the root directory.....
Sorry for the noise..
-
Ah, so you didn't follow the wiki instructions after all. Easy enough to fix, though. Create /etc/letsencrypt.sh, put config.sh and domains.txt in there, and you should be good.
-
Ah, so you didn't follow the wiki instructions after all.
:-) All fixed now. Thanks.
-
The git clone to download letsencrypt.sh should have been done from inside /etc/
Important!
-
I know that's in the wiki page, but if it needs to be made more prominent, feel free. Another option would be to clone it somewhere elsewhere, and manually create /etc/letsencrypt.sh and the two config files there.
-
If using the webapps-common contrib to create a subdomain (e.g. chat.myserver.local), the Letsencrypt script will fail for the chat.myserver.local domain. This is because the ProxyPassTarget property will forward to another http server instead of the SME Server apache.
Any thoughts on how to prevent the (cron job or manually) fail?
-
Update the contrib so that the letsencrypt URL goes to the right place.
-
Think there are a few things to be looked at.... sub domains themselves work with the letsencrypt contrib. But I tried to keep it simple... complexity can accelerate away.
The issue is the way rocketchat works.
Couple of thoughts...
For letsencrypt the sub domain has to have a http reachable .wellknown directory
Rocket works on 3000. We are using the proxy mod to enable https redirection/access to http :3000
My suggestion would be when creating the rocket account we set the default ibay as Primary.
Then use a redirect rule that ONLY redirects httpS calls to port 3000
Standards http calls to 80 go as normal to Primary (and possibly limit it to calls to .wellknkown with everything else going to http:3000)
That may be a far simpler solution.
In any event I have no idea what nodejs/rocket considers its 'base' directory so it's tricky to know where to add a .wellknown directory.
I think this is a configuration that needs to be solved in rocket rather than letsencrypt.
Rgds
JC
-
I think this is a configuration that needs to be solved in rocket rather than letsencrypt.
Maybe, but looking at a 'lower level' (before the https request that hits rocket) it passes Apache. So if webapps-common can take into account how to cope with httpS requests to letxencrypt it would be solved I guess.. It already does to for normal http requests and takes letsencrypt into account.
All maybe here..
Maybe Daniel can share his thoughts?
-
Yes, either in web apps or via the redirect required for rocket.
I believe JPP was going to try and rewrite stuff to allow for letsencrypt out of the box. The whole thing is in a state of flux right now.
I still think for now an apache template for rocket would be easiest.... each contrib sorting out its own vagaries or special requirements. It can then be backed out if other things come to fruition. Unfortunately I am (freezing myself) in the UK next week so won't have any time to play but should be ok thereafter
Rgds
John
-
If using the webapps-common contrib to create a subdomain (e.g. chat.myserver.local), the Letsencrypt script will fail for the chat.myserver.local domain. This is because the ProxyPassTarget property will forward to another http server instead of the SME Server apache.
This is not correct, at least for me when using John's RPM for letsencrypt.sh. I don't think I can explain why, but I was able to obtain a LE cert for chat.mydomain without a problem.
-
Think it is a case of YMMV :-)
What HSF has had an issue with is running a subdomain with rocket chat and mod proxy to redirect calls to the subdomain. I noticed this myself.
I believe the solution is to make a better http template for rocket as above.
-
If using the webapps-common contrib to create a subdomain (e.g. chat.myserver.local), the Letsencrypt script will fail for the chat.myserver.local domain. This is because the ProxyPassTarget property will forward to another http server instead of the SME Server apache.
The WebAppVirtualHost templates provided in webapps-common has a prop to control what to do with this. When you create a virtualhost with a ProxyPassTarget, you can set the ProxyPassACMEChallenges prop. Valid values are:
- disabled: (default): do not proxypass ACME challenges requests to the target. The requests are handled by apache directly
- only: only forward ACME challenges to the target. Everything else is served by apache directly
- enabled: forward everything to the target, including ACME challenges
So, your issue is not that ACME challenge requests (/.well-known/acme-challenge/) are forwarded to the target (they are not). It's because there's no alias to handle it in the virtualhost. This should be added in the Letsencrypt contrib. It's just a matter of adding somthing like
Alias /.well-known/acme-challenge/ /path/to/the/acme/challenge/dir
-
What HSF has had an issue with is running a subdomain with rocket chat and mod proxy to redirect calls to the subdomain. I noticed this myself.
I understand that. I'm running the same combination, and obtaining the LE cert works for me. Obviously there's something different between our setups (and in light of Daniel's post, maybe that's that I'm running a newer version of webapps-common than you two), but it's not universally the case that following the Rocket.chat instructions will cause LE cert issuance to fail.
-
Think I have twigged something. In the letsencypt contrib I think I have missed a trailing slash in the file /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts/40ACME
It is currently like this:
# Alias for letsencrypt
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
I think it should be like this:
# Alias for letsencrypt
Alias /.well-known/acme-challenge/ /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
That matches the proxypass ignore line
ProxyPass /.well-known/acme-challenge/ !
and I can then get to this URL without Rocket interfering :
http://chat.reetspetit.info/.well-known/acme-challenge/
Can someone test/advise if this is right please ?
B. Rgds
John
-
For those who are interested....
I have updated the basic letsencrypt rpm with v2 of the script. Unfortunately due to an act of complete stupidity on my part I misnumbered the contrib originally so have had to bastardise it a bit.
New version is letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.rpm
v8 : https://www.reetspetit.com/smeserver/5/noarch/letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.rpm
v9 : https://www.reetspetit.com/smeserver/6/noarch/letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.rpm
You can try yum --enablerepo=reetp clean metadata and then install. If not you might need to wget and yum localinstall to force it to update
I will patch the missing trailing slash in 40ACME for the smeserver-letsencrypt contrib shortly - still thinking how to do an 'all' for all domains/hosts.
-
I have updated the basic letsencrypt rpm with v2 of the script.
Strange, looks like it isn't seeing the config file any more:
[root@e-smith ~]# letsencrypt.sh -c
#
# !! WARNING !! No main config file found, using default config!
#
ERROR: WELLKNOWN directory doesn't exist, please create /usr/local/bin/.acme-challenges and set appropriate permissions.
[root@e-smith ~]# cd /etc/letsencrypt.sh/
[root@e-smith letsencrypt.sh]# ls
certs config.sh domains.txt private_key.pem
[root@e-smith letsencrypt.sh]# rpm -qa | grep letsencrypt
letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch
smeserver-letsencrypt-0.2-2.noarch
[root@e-smith letsencrypt.sh]#
Edit: Almost looks like it's looking for config, not config.sh:
# Setup default config values, search for and load configuration files
load_config() {
# Check for config in various locations
if [[ -z "${CONFIG:-}" ]]; then
for check_config in "/etc/letsencrypt.sh" "/usr/local/etc/letsencrypt.sh" "${PWD}" "${SCRIPTDIR}"; do
if [[ -e "${check_config}/config" ]]; then
BASEDIR="${check_config}"
CONFIG="${check_config}/config"
break
fi
done
fi
Edit 2: And indeed, that's what's happened: https://github.com/lukas2511/letsencrypt.sh/commit/d5b285868e35992027599d25411d80dfd0bf1048
-
Edit 2: And indeed, that's what's happened: https://github.com/lukas2511/letsencrypt.sh/commit/d5b285868e35992027599d25411d80dfd0bf1048 (https://github.com/lukas2511/letsencrypt.sh/commit/d5b285868e35992027599d25411d80dfd0bf1048)
Good catch!
edit: wiki page adapted.
-
Ahhhh good one Dan. I'll update my contrib too.
Buggers...... why can't they just leave alone ?
-
For the time being, I just made a symlink (ln -s config.sh config), which seems to be working.
-
I'm just hacking the contrib whilst waiting for wife to get back from her hysterctomoy op :-)
-
I will patch the missing trailing slash in 40ACME for the smeserver-letsencrypt contrib shortly - still thinking how to do an 'all' for all domains/hosts.
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';
# is all ?
my $allstatus= $configDB->get_prop( 'letsencrypt', 'AllDomainDefault' ) || 'disabled';
# First get all the domains
foreach my $domain (@domains) {
# my $domainEnabled = $domainsDB->get_prop( "$domain", 'letsencryptSSLcert' ) || 'disabled';
my $domainEnabled = $domainsDB->get_prop( "$domain", 'letsencryptSSLcert' ) || $allstatus;
if ( $domainEnabled eq 'enabled' ) {
#code
$OUT .= "$domain ";
}
this way the default will be al disabled
you can enable all
you can enable all BUT the one that are strictly disabled :D
if you forgot to remove the disabled in a domain, well screw you ;) , you just have to check !
-
:lol:
I have got something a little more subtle... but you have given me an idea to modify it a bit further. Will try and push an update later today.
-
Think I have twigged something. In the letsencypt contrib I think I have missed a trailing slash in the file /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts/40ACME
It is currently like this:
# Alias for letsencrypt
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
I think it should be like this:
# Alias for letsencrypt
Alias /.well-known/acme-challenge/ /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
That matches the proxypass ignore line
ProxyPass /.well-known/acme-challenge/ !
defintively not to do, this led me to a 404 on the file in the acme directory : apache can list the file, but it is 404 when calling it, resulting in a failure to validate regular domains.
[Tue May 31 02:52:46 2016] [error] [client i.i.i.i] File does not exist: /home/e-smith/files/ibays/Primary/html/.well-known/acme-challengeTyV3pKWG-uCW42aNRgb0vXvWKZV8Yl4_dsdGw_LX-1E, referer: http://f.f.com/.well-known/acme-challenge/
see the rewriting lost a / ;)
i can however confirm that :
# Alias for letsencrypt
Alias /.well-known/acme-challenge/ /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge/
would work with Primary domain , I hope this also solve the Rocket issue
-
I have updated the letsencrypt rpms
smeserver-letsencrypt-0.2-5.noarch
letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch (contains v2 of the letsencrypt script)
Due to a trip to cockup city on my part with numbering the smeserver-letsencrypt rpm may not want to drag in the newer letsencrypt.sh rpm which it needs for letsencrypt.sh v2
You can grab a copy from my repo and install locally, or remove and reinstall all.
Brief Notes :
Modified the 40ACME URLs to add trailing /
Modified slightly the bash scripts in the spec file
Added new config entry :
You can now use 'all' to set all domains or hosts regardless of status
config setprop letsencrypt letsencyptConfig all | domains | hosts
Delete the key to go back to normal
Don't use it unless you know what you are doing...... and make sure you are in TEST mode first.
Please test (on a VM !)
Off to hospital again :-(
-
Strange, looks like it isn't seeing the config file any more:
[root@e-smith ~]# letsencrypt.sh -c
#
# !! WARNING !! No main config file found, using default config!
#
ERROR: WELLKNOWN directory doesn't exist, please create /usr/local/bin/.acme-challenges and set appropriate permissions.
[root@e-smith ~]# cd /etc/letsencrypt.sh/
[root@e-smith letsencrypt.sh]# ls
certs config.sh domains.txt private_key.pem
[root@e-smith letsencrypt.sh]# rpm -qa | grep letsencrypt
letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch
smeserver-letsencrypt-0.2-2.noarch
[root@e-smith letsencrypt.sh]#
Edit: Almost looks like it's looking for config, not config.sh:
# Setup default config values, search for and load configuration files
load_config() {
# Check for config in various locations
if [[ -z "${CONFIG:-}" ]]; then
for check_config in "/etc/letsencrypt.sh" "/usr/local/etc/letsencrypt.sh" "${PWD}" "${SCRIPTDIR}"; do
if [[ -e "${check_config}/config" ]]; then
BASEDIR="${check_config}"
CONFIG="${check_config}/config"
break
fi
done
fi
Edit 2: And indeed, that's what's happened: https://github.com/lukas2511/letsencrypt.sh/commit/d5b285868e35992027599d25411d80dfd0bf1048
I followed the wiki install instructions :
yum install smeserver-letsencrypt --enablerepo=reetp
reetp/primary_db | 128 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package smeserver-letsencrypt.noarch 0:0.2-5 will be installed
--> Processing Dependency: letsencrypt.sh >= 0.0.9 for package: smeserver-letsen crypt-0.2-5.noarch
--> Running transaction check
---> Package letsencrypt.sh.noarch 0:0.0.9.160523.gitd5b2858-1 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository
Size
================================================================================
Installing:
smeserver-letsencrypt noarch 0.2-5 reetp 26 k
Installing for dependencies:
letsencrypt.sh noarch 0.0.9.160523.gitd5b2858-1 reetp 21 k
Transaction Summary
================================================================================
Install 2 Package(s)
Total download size: 48 k
Installed size: 84 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.r | 21 kB 00:00
(2/2): smeserver-letsencrypt-0.2-5.noarch.rpm | 26 kB 00:00
--------------------------------------------------------------------------------
Total 42 kB/s | 48 kB 00:01
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch 1/2
Installing : smeserver-letsencrypt-0.2-5.noarch 2/2
/var/tmp/rpm-tmp.TRCbMd: line 5: [[!: command not found
/var/tmp/rpm-tmp.TRCbMd: line 9: [[!: command not found
/var/tmp/rpm-tmp.TRCbMd: line 13: [[!: command not found
/var/tmp/rpm-tmp.TRCbMd: line 17: [[!: command not found
/var/tmp/rpm-tmp.TRCbMd: line 21: [[!: command not found
###################################################################
# After install please set your db keys
# Make sure you set the letsencrypt status key to test
# Enable some domains or hosts
# Then run the following
# signal-event console-save
# letsencrypt.sh -c
# Once you are satisfied set the letsencrypt status key to enabled
# mv /etc/letsencrypt.sh/private_key.pem /etc/letsencrypt.sh/private_key.test
# Run the letesencypt.sh file again to generate your keys
# signal-event console-save
# letsencrypt.sh -c -x
# Thereafter only use
# letsencrypt.sh -c
# If you make any key changes run console-save first
###################################################################
Migrating existing database spamassassin
Migrating existing database domains
Migrating existing database hosts
Migrating existing database configuration
Migrating existing database yum_repositories
Migrating existing database accounts
Migrating existing database networks
Migrating existing database yum_installed
Migrating existing database yum_available
Migrating existing database yum_updates
Migrating existing database mailpatterns
Migrating existing database backups
Verifying : smeserver-letsencrypt-0.2-5.noarch 1/2
Verifying : letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch 2/2
Installed:
smeserver-letsencrypt.noarch 0:0.2-5
Dependency Installed:
letsencrypt.sh.noarch 0:0.0.9.160523.gitd5b2858-1
Complete!
==============================================================
WARNING: You now need to run BOTH of the following commands
to ensure consistent system state:
signal-event post-upgrade; signal-event reboot
You should run these commands unless you are certain that
yum made no changes to your system.
Then ran :
expand-template /etc/httpd/conf/httpd.conf
service httpd-e-smith restart
Followed by adding db settings : ( set correct email domain
# config setprop letsencypt email admin@myactualdomain.com
# config setprop letsencrypt status test
# db domains setprop myactualdomain.com letsencryptSSLcert enabled
# signal-event console-save
and am getting the following Error when running letsencrypt.sh -c -x
# letsencrypt.sh -c
# INFO: Using main config file /etc/letsencrypt.sh/config
+ Generating account key...
+ Registering account key with letsencrypt...
ERROR: domains.txt not found and --domain not given
If i look in the quote from Dan35 above i see that in /etc/letsencrypt.sh there is a file called : domains.txt
Question , must this be manually created ?
does the db domains setprop myactualdomain.com letsencryptSSLcert enabled and signal-event console-save not create this file ?
If i manually create the file /etc/letsencrypt.sh/domains.txt with the domain name in it , then the command letsencrypt.sh -c -x runs without errors
-
With the new version of letsecncrypt.sh 'config.sh' was renamed to 'config' (their decision, not mine)
domains.txt should be created on a signal-event console-save
Can you do :
cat /etc/letsencrypt.sh/domains.txt
You shouldn't have to expand any templates such as httpd - it should be done for you on a console-save
Read here for more details on setup
https://github.com/reetp/smeserver-letsencrypt/tree/smeserver-letsencrypt-0.2
Make sure you use test mode until everything seems to work. Check your logs e.g. /var/log/messages for any processing errors.
Post back if you have issues.
B. Rgds
John
-
warren,
maybe it is not created or empty if the domains / hosts configuration and individual domains are not set to enabled, which you did not described in the steps you gave, check the new procedure of the newly built rpm.
-
Hi John
Posted by: ReetP
« on: Today at 04:53:13 AM »
domains.txt should be created on a signal-event console-save
I found that this was not the case. Error below is what set me to look to see if domains.txt had been created.
Posted by: warren
« on: Today at 04:04:30 AM »
# letsencrypt.sh -c
# INFO: Using main config file /etc/letsencrypt.sh/config
+ Generating account key...
+ Registering account key with letsencrypt...
ERROR: domains.txt not found and --domain not given
Can you do :
cat /etc/letsencrypt.sh/domains.txt
This file is there , I created manually. and it contains the correct domain name in following format:
myactualdomain.com
-
warren,
maybe it is not created or empty if the domains / hosts configuration and individual domains are not set to enabled, which you did not described in the steps you gave, check the new procedure of the newly built rpm.
I ran the command to enable the domains as below :
I followed the wiki install instructions :
yum install smeserver-letsencrypt --enablerepo=reetp
.....
# After install please set your db keys
# Make sure you set the letsencrypt status key to test
# Enable some domains or hosts
# Then run the following
# signal-event console-save
# letsencrypt.sh -c
# Once you are satisfied set the letsencrypt status key to enabled
# mv /etc/letsencrypt.sh/private_key.pem /etc/letsencrypt.sh/private_key.test
# Run the letesencypt.sh file again to generate your keys
# signal-event console-save
# letsencrypt.sh -c -x
# Thereafter only use
# letsencrypt.sh -c
# If you make any key changes run console-save first
Then ran :
expand-template /etc/httpd/conf/httpd.conf
service httpd-e-smith restart
Followed by adding db settings : ( set correct email domain
# config setprop letsencypt email admin@myactualdomain.com
# config setprop letsencrypt status test
# db domains setprop myactualdomain.com letsencryptSSLcert enabled
# signal-event console-save
....
Also seems to be a disconnect between wiki instructions and those on https://github.com/reetp/smeserver-letsencrypt/blob/smeserver-letsencrypt-0.2/README.md (https://github.com/reetp/smeserver-letsencrypt/blob/smeserver-letsencrypt-0.2/README.md)
-
Found a typo (doing stuff in a hurry) - if you had looked in /var/log/messages first you would have seen it immediately no doubt (always check logs first - it helps a lot)
Try the following:
The following default db key should really be none and not all :
To check:
cat /etc/e-smith/db/configuration/defaults/letsencrypt/configure
If it says all then change it :
sed -i 's/all/none/' /etc/e-smith/db/configuration/defaults/letsencrypt/configure
Copy your file out of the way for safety
cp /etc/e-smith/templates/etc/letsencrypt.sh/domains.txt/10Domains ~/10Domains.backup
Fix my dodgy typos
sed -i 's/encypt/encrypt/g' /etc/e-smith/templates/etc/letsencrypt.sh/domains.txt/10Domains
Expand the template
expand-template /etc/letsencrypt.sh/domains.txt
And check
cat /etc/letsencrypt.sh/domains.txt
That should fix it and I'll push a fixed rpm tomorrow
Try varying the settings in test mode (followed by a console-save for each change) and run letsencrypt.sh and see what happens. Check your logs.....
Notes.....
1. You do not need to expand the httpd template or restart httpd with the rpm. It does this automagically for you (the wiki is incorrect as a console-save does this for you)
2. Yes, there may be difference between git and the wiki. This was built for my use and I give no guarantees on anything else..... I have been busy lately, updated git but not the wiki for v0.2
Thanks for taking the time to report this.
B. rgds
John
-
0.2-6 in repo now - with above fixes.
yum --enablerepo=reetp install smeserver-letsencrypt
Please let me know what happens.
B. Rgds
John
-
Note I have also spotted a cockup in the file handling department in the spec file - it won't affect anything - it's just there to move old files out of the way. Will fix later.
-
Busy testing now... wil revert.
Note : Also Spelling errors in both wiki https://wiki.contribs.org/Letsencrypt#Install_with_John_Crisp_contrib (https://wiki.contribs.org/Letsencrypt#Install_with_John_Crisp_contrib) have highlighted incorrect spelling in red.
set email
config setprop letsencypt email my@email.com
and https://github.com/reetp/smeserver-letsencrypt/blob/smeserver-letsencrypt-0.2/README.md (https://github.com/reetp/smeserver-letsencrypt/blob/smeserver-letsencrypt-0.2/README.md)
config setprop letsencypt email (defaults to empty)
config setprop letsencypt keysize (defaults to 4096)
-
Cool. Way past my bed time but will fix on the morning.
B. Rgds
Johm
-
Found a typo (doing stuff in a hurry) - if you had looked in /var/log/messages first you would have seen it immediately no doubt (always check logs first - it helps a lot)
Try the following:
The following default db key should really be none and not all :
To check:
cat /etc/e-smith/db/configuration/defaults/letsencrypt/configure
If it says all then change it :
sed -i 's/all/none/' /etc/e-smith/db/configuration/defaults/letsencrypt/configure
Copy your file out of the way for safety
cp /etc/e-smith/templates/etc/letsencrypt.sh/domains.txt/10Domains ~/10Domains.backup
Fix my dodgy typos
sed -i 's/encypt/encrypt/g' /etc/e-smith/templates/etc/letsencrypt.sh/domains.txt/10Domains
Expand the template
expand-template /etc/letsencrypt.sh/domains.txt
And check
cat /etc/letsencrypt.sh/domains.txt
That should fix it and I'll push a fixed rpm tomorrow
Try varying the settings in test mode (followed by a console-save for each change) and run letsencrypt.sh and see what happens. Check your logs.....
The above worked, with all variations of hosts / domains , thank-you.
2. Yes, there may be difference between git and the wiki. This was built for my use and I give no guarantees on anything else..... I have been busy lately, updated git but not the wiki for v0.2
Thank you John for developing this We all appreciate yours and all who contribute to Koozali SME Server , and all deserve to be bought a couple of :pint: :pint:
Have update wiki as well.
-
0.2-6 in repo now - with above fixes.
yum --enablerepo=reetp install smeserver-letsencrypt
Please let me know what happens.
B. Rgds
John
Confirming that this works.
-
Fantastic - thank you very much for testing and doing the wiki... !
There is one additional setting as per git - I have added this to the wiki :
You can now use a db entry to set all domains or hosts regardless of status
config setprop letsencrypt letsencryptConfig none| all | domains | hosts
default is none
If you set to domains it will enable ALL domains regardless of individual settings. Hosts will be per host as normal.
If you set to hosts it will enable ALL hosts regardless of individual settings. Domains will be per domain as normal
If you set to all it will enable ALL hosts AND domains regardless of individual settings.
I am trying to track updates to the letsencrypt.sh script and will release a new version of that if there are any serious bugs or required modifications.
Let me know if there are further issues.
B. Rgds
John
-
Thank you :smile:
Just an observation , i need to re-test to make sure it was not a finger slip, but it seems that you need to add each individual host separately when doing :
db hosts setprop...
in that this did not seem to work :
db hosts setprop www.mydomain.com proxy.mydomain.com wpad.mydomain.com letsencryptSSLcert enabled
signal-event console-save
Instead you have to do each host individually :
db hosts setprop www.mydomain.com letsencryptSSLcert enabled
db hosts setprop wpad.mydomain.com letsencryptSSLcert enabled
...
signal-event console-save
-
Thank you :smile:
Thanks where they are due :-)
Just an observation , i need to re-test to make sure it was not a finger slip, but it seems that you need to add each individual host separately when doing :
db hosts setprop...
in that this did not seem to work :
db hosts setprop www.mydomain.com proxy.mydomain.com wpad.mydomain.com letsencryptSSLcert enabled
signal-event console-save
Instead you have to do each host individually :
db hosts setprop www.mydomain.com letsencryptSSLcert enabled
db hosts setprop wpad.mydomain.com letsencryptSSLcert enabled
...
signal-event console-save
Quite possibly, but that would be a limitation/restriction of the current db system AFAIAA.
Only way round that 'easily' would be to have a server panel and a set of check boxes. I have never written a panel and am completely clueless about such things - quite frankly it's a miracle I a) coded something in perl and b) built a contrib/RPM
IF I ever get 3 minutes free I may have a look, but right now I am up to my neck in the smelly stuff !
B. Rgds
John
-
Thanks where they are due :-)
Quite possibly, but that would be a limitation/restriction of the current db system AFAIAA.
Only way round that 'easily' would be to have a server panel and a set of check boxes. I have never written a panel and am completely clueless about such things - quite frankly it's a miracle I a) coded something in perl and b) built a contrib/RPM
IF I ever get 3 minutes free I may have a look, but right now I am up to my neck in the smelly stuff !
B. Rgds
John
I may repeat myself, but instead of using on property as a switch for domains all or hosts, having
- property hosts enabled/disabled
- property domains enabled/disabled
and using these two values as the default behaviour to all domain/hosts that are not defined individually, you can do it easily ;) as I showed earlier
-
I may repeat myself, but instead of using on property as a switch for domains all or hosts, having
- property hosts enabled/disabled
- property domains enabled/disabled
and using these two values as the default behaviour to all domain/hosts that are not defined individually, you can do it easily ;) as I showed earlier
I get what you mean now. I can take a look when I get a moment.
-
Anyone have some thoughts on mixed content on a Letsencrypt secured connection?
https://www.bennish.net/mixed-content.html (https://www.bennish.net/mixed-content.html)
It seems it is possible to bypass HTTPS by embedding objects from non secure sites... In the above example you will see the https connection turn grey because http content is being embedded.
More info https://github.com/atmos/camo
-
This is not Letsencrypt specific. Most browsers handle it in some way (either block mixed content, warn the user, mark the connexion as insecure)
-
>>Most browsers handle it in some way (either block mixed content, warn the user, mark the connexion as insecure)
Agreed. It's a feature. Useful when proofing an old http page into a new https page:-)
-
This is not Letsencrypt specific.
Agreed. My thought on mixed content is that it should be avoided when possible, but it isn't something that's really related to Let's Encrypt or any other CA.
-
The official Let's Encrypt client has been renamed to certbot and moved to another location. It still has the same dependency issues with SME9. Since letsencrypt.sh has no dependency issues with SME8 or SME9, I propose removing the sections of the wiki that deal with the official client, and leaving the manual installation and use of letsencrypt.sh, and the section on John's contrib. Thoughts?
-
The official Let's Encrypt client has been renamed to certbot and moved to another location. It still has the same dependency issues with SME9. Since letsencrypt.sh has no dependency issues with SME8 or SME9, I propose removing the sections of the wiki that deal with the official client, and leaving the manual installation and use of letsencrypt.sh, and the section on John's contrib. Thoughts?
Agree, we should remove it. We can only document what we can support and what works stable for Koozali SME Server.
-
>>Thoughts?
Agreed.
-
Done.
The procedures for generating certs for internal servers will need to be updated, as they were also written for the official client. I didn't want to remove the topic heading, but I have a warning box there now.
-
I updated to smeserver-letsencrypt yesterday to 0.2-6, and it's behaving in a way that's (1) odd, and (2) inconsistent with the documentation at https://github.com/reetp/smeserver-letsencrypt/tree/smeserver-letsencrypt-0.2.
The github page says there's a property called letsencryptConfig that defaults to none and controls which hostnames will be on a certificate. My install has created a property called configure and set it to all (which I didn't manually do), resulting in the system trying to obtain a cert for every known hostname. Setting that property to none and re-expanding domains.txt has given the desired result.
-
I updated to smeserver-letsencrypt yesterday to 0.2-6, and it's behaving in a way that's (1) odd, and (2) inconsistent with the documentation at https://github.com/reetp/smeserver-letsencrypt/tree/smeserver-letsencrypt-0.2.
The github page says there's a property called letsencryptConfig that defaults to none and controls which hostnames will be on a certificate. My install has created a property called configure and set it to all (which I didn't manually do), resulting in the system trying to obtain a cert for every known hostname. Setting that property to none and re-expanding domains.txt has given the desired result.
Dan - sorry - I'll check that and get it fixed pronto.
-
It's my awful documentation.
config setprop letsencrypt configure none| all | domains | hosts
I use a variable in the scripts called $letsencryptConfig and got in a muddle somewhere.
-
There's also the matter of the default. It seems it was set in the post-install script to all, which really doesn't seem like a sensible default at all, whatever the property is called.
-
There's also the matter of the default. It seems it was set in the post-install script to all, which really doesn't seem like a sensible default at all, whatever the property is called.
Damn - can you just check the db/default file ? Definitely 'all' ?
I have it here as none but perhaps I changed it and never built an updated RPM.
Let me know and I'll get an update smashed out PDQ
-
v0.2-7 in my repo
-
Damn - can you just check the db/default file ? Definitely 'all' ?
Sorry, where is the db/default file? The "configure" property was set to "all", and I don't believe I did that manually.
-
Sorry, where is the db/default file? The "configure" property was set to "all", and I don't believe I did that manually.
/etc/e-smith/db/configuration/defaults/letsencrypt
As per my post above I made a mistake in the docs which I have corrected.
I think the version you had also may also had the configure (the correct property name) property set to 'all' rather than 'none'.
The new RPM should set the correct DB key value of none and to use the key do :
config setprop letsencrypt configure none | all | domains | hosts (use one value)
Let me know if anything seems amiss.
-
/etc/e-smith/db/configuration/defaults/letsencrypt
Strange--I looked there, and "configure" contained "none". I've now manually changed that property to "none", and domains.txt looks like it should, but I wonder what set it to "all".
I'll install the update.
-
I think I did the first version of this and set it to all in testing and that got left in. You have got it at some point I guess.
Please keep me posted, though bed time for me now.
-
Dan,
I just noticed this with certs per domain in their own directories et al.
https://github.com/lukas2511/letsencrypt.sh/pull/242
a) relevant ?
b) anything worth adding ?
I'll have to pull in the script at some stage and this doe not seem to actually affect anything - just gives more functionality
Let me know you thoughts.
B. Rgds
John
-
From what I can tell, that change isn't going to make a big difference. It allows specifying a directory which can contain per-domain configuration files, but it doesn't appear to require that. It seems to me that in our application, implementing this would be an unnecessary complication.
-
Does me !!
Thanks
-
Hi John,
Installing the latest rpm I get this error message:
Running Transaction
Installing : letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch 1/2
Installing : smeserver-letsencrypt-0.2-7.noarch 2/2
/var/tmp/rpm-tmp.lmNfdo: line 5: syntax error in conditional expression: unexpected token `;'
/var/tmp/rpm-tmp.lmNfdo: line 5: syntax error near `;'
/var/tmp/rpm-tmp.lmNfdo: line 5: `if [[ -f /etc/letsencrypt.sh/config.sh]];'
warning: %post(smeserver-letsencrypt-0.2-7.noarch) scriptlet failed, exit status 2
Non-fatal POSTIN scriptlet failure in rpm package smeserver-letsencrypt-0.2-7.noarch
Migrating existing database yum_repositories
Everything seems to work OK though?
-
Hi sorry but I realised there were some bash errors in the postinstall script in this version.
The scripts just try and clean out old config files.... as the system creates clean ones it shouldn't be an issue on an update. It may affect a new install by not creating the acme directory.
I think I built a new fixed rpm last week but following a panic at work I forgot to add it to the repo. I'll try and take a look later today (I'm travelling & stuff so as time allows)
B. Rgds
John
-
Thanks John - good work.
-
It seems they have updated their conditions:
# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
+ Generating account key...
+ Registering account key with letsencrypt...
+ ERROR: An error occurred while sending post-request to https://acme-staging.api.letsencrypt.org/acme/new-reg (Status 400)
Details:
{
"type": "urn:acme:error:malformed",
"detail": "Provided agreement URL [https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf] does not match current agreement URL [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]",
"status": 400
}
-
also got this :
Set up modSSL db keys
Signal events
Can't open directory /etc/e-smith/events/ssl-update
All complete
+ Done!
-
It seems they have updated their conditions:
# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
+ Generating account key...
+ Registering account key with letsencrypt...
+ ERROR: An error occurred while sending post-request to https://acme-staging.api.letsencrypt.org/acme/new-reg (Status 400)
Details:
{
"type": "urn:acme:error:malformed",
"detail": "Provided agreement URL [https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf] does not match current agreement URL [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]",
"status": 400
}
Yes I need to build a new version. Will do ASAP - there was some debate on their list that hard coding this was a pain
https://github.com/lukas2511/letsencrypt.sh/issues/249#issuecomment-236711759
I'll get to it soonest, unless anyone has an alternative solution
-
yes, I have seen it could be also in configuration
also check for the event folder missing
last here a suggestion to have the main domain first and not to have it twice ( I have some server with multiple domain, and the alphabetical order, gives one of the client domain as first domain.. not nice)
# diff -Nur /etc/e-smith/templates/etc/letsencrypt.sh/domains.txt/10Domains /etc/e-smith/templates-custom/etc/letsencrypt.sh/domains.txt/10Domains
--- /etc/e-smith/templates/etc/letsencrypt.sh/domains.txt/10Domains 2016-07-14 07:47:28.000000000 -0400
+++ /etc/e-smith/templates-custom/etc/letsencrypt.sh/domains.txt/10Domains 2016-08-03 08:06:54.000000000 -0400
@@ -38,6 +38,11 @@
# We could do this BUT only once as the array drops $vars
# my $dom = shift @domains;
+ #JP put Primary domain at top
+ my $DomainName= $configDB->get('DomainName')->value;
+ my $mainDomainStatus= $domainsDB->get_prop( "$DomainName", 'letsencryptSSLcert' )
+ || 'disabled';
+ $OUT .= "$DomainName " unless $mainDomainStatus eq 'disabled';
foreach my $domain (@domains) {
@@ -62,7 +67,7 @@
if ( $domainEnabled eq 'enabled' ) {
- $OUT .= "$domain ";
+ $OUT .= "$domain " unless $DomainName eq $domain;
}
}
@@ -76,7 +81,7 @@
# If we are set to all or hosts just do it
if ( $letsencryptConfig eq 'all' || $letsencryptConfig eq 'hosts' ) {
- $OUT .= "$fqdn ";
+ $OUT .= "$fqdn " unless $DomainName eq $fqdn;
}
# Just do selected entries
@@ -107,7 +112,7 @@
if ( $type eq 'Self' ) {
# print "$fqdn $type\n";
- $OUT .= "$fqdn ";
+ $OUT .= "$fqdn " unless $DomainName eq $fqdn;
}
-
I can see that I need to vary the code depending on the version - it works on v9 but not on v8.
Just done a 'system check' now - the hook commands vary depending on whether you have v8 or a later version in stalled.
Have added a key for 'licence' so if the licence changes you can override the default set in letsencrypt.sh
e.g.
config setprop letsencrypt licence https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf
New RPMs in my repo:
smeserver-letsencrypt-0.2-9
letsencrypt.sh-0.0.9.160803.gitafabfff-1
Please test.
-
last here a suggestion to have the main domain first and not to have it twice ( I have some server with multiple domain, and the alphabetical order, gives one of the client domain as first domain.. not nice)
# diff -Nur blah
Sorry - I had built most of the new version by the time you sent your patch.
I'll look at adding this soonest
-
smeserver-letsencrypt-0.2-10 built and in my repo
Please test
-
John great work with this update!
I have set a few servers today and I kept getting the following errors:
either when starting the script
# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
ERROR: Problem connecting to server (get for https://acme-staging.api.letsencrypt.org/directory; curl returned with 6)
or at the end
+ Creating fullchain.pem...
ERROR: Problem connecting to server (get for http://cert.stg-int-x1.letsencrypt.org/; curl returned with 6)
only workaround I found is service dnscache restart
any idea ?
-
just to say the servers is able to resolve :
# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
+ Generating account key...
+ Registering account key with letsencrypt...
Processing ....
+ Signing domains...
....
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
ERROR: Problem connecting to server (get for http://cert.int-x3.letsencrypt.org/; curl returned with 6)
[root@hebergement.sansfrontieres.ca:~]# host cert.int-x3.letsencrypt.org
cert.int-x3.letsencrypt.org is an alias for cert.int-x3.letsencrypt.org.akamaized.net.
cert.int-x3.letsencrypt.org.akamaized.net is an alias for a1466.dscd.akamai.net.
a1466.dscd.akamai.net has address 67.69.196.186
a1466.dscd.akamai.net has address 67.69.196.184
a1466.dscd.akamai.net has IPv6 address 2001:4958:300:45e::b896:a30b
a1466.dscd.akamai.net has IPv6 address 2001:4958:300:45e::b896:a318
-
I have the exact same problems.
-
OK, I just did the following on a v9.x box
[root@photos ~]# yum --enablerepo=reetp update
[root@photos ~]# signal-event post-upgrade; signal-event reboot
[root@photos ~]# rpm -qa |grep letsencrypt
letsencrypt.sh-0.0.9.160803.gitafabfff-1.noarch
smeserver-letsencrypt-0.2-10.noarch
[root@photos ~]# letsencrypt.sh -c
# INFO: Using main config file /etc/letsencrypt.sh/config
! Moving private_key.pem to /etc/letsencrypt.sh/accounts/aHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2RpcmVjdG9yeQo/account_key.pem
! Moving private_key.json to /etc/letsencrypt.sh/accounts/aHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2RpcmVjdG9yeQo/registration_info.json
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
[root@photos ~]# letsencrypt.sh -c
# INFO: Using main config file /etc/letsencrypt.sh/config
Processing photos.reetspetit.info
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Oct 12 11:23:00 2016 GMT (Longer than 30 days). Skipping renew!
[root@photos ~]# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
Processing photos.reetspetit.info
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Oct 12 11:23:00 2016 GMT (Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for photos.reetspetit.info...
+ Responding to challenge for photos.reetspetit.info...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
Set up modSSL db keys
Signal events
All complete
+ Done!
Here's my asterisk v9 box - it threw errors twice and then resolved:
[root@asterisk letsencrypt.sh]# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
[root@asterisk letsencrypt.sh]# wget https://acme-v01.api.letsencrypt.org/directory
--2016-08-03 22:41:49-- https://acme-v01.api.letsencrypt.org/directory
Resolving acme-v01.api.letsencrypt.org... 23.206.21.80, 2a02:26f0:2d:480::3d5, 2a02:26f0:2d:487::3d5
Connecting to acme-v01.api.letsencrypt.org|23.206.21.80|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 280 [application/json]
Saving to: “directory”
[root@asterisk letsencrypt.sh]# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
+ Generating account key...
+ Registering account key with letsencrypt...
Processing asterisk.impamark.co.uk
+ Signing domains...
+ Creating new directory /etc/letsencrypt.sh/certs/asterisk.impamark.co.uk ...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for asterisk.impamark.co.uk...
+ Responding to challenge for asterisk.impamark.co.uk...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
ERROR: Problem connecting to server (get for http://cert.int-x3.letsencrypt.org/; curl returned with 6)
[root@asterisk letsencrypt.sh]# letsencrypt.sh -c -x
# INFO: Using main config file /etc/letsencrypt.sh/config
Processing asterisk.impamark.co.uk
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for asterisk.impamark.co.uk...
+ Responding to challenge for asterisk.impamark.co.uk...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
Set up modSSL db keys
Signal events
All complete
+ Done!
The Cert looks like it was dated 14/7/2016 (you can view it at the site)
The only things I can guess at (and I am no expert on this) is that the letsencrypt.sh script has changed a bit as you can see from the output above and I wonder if any of those changes have had an effect - you may need to use -x the first time after the update.
Whether it is an issue with letsencrypt servers, or an issue with Koozali SME server I do not know.
-
As a note I have had issues with both v8 and v9 boxes. They have all resolved on the second or third attempt with letsencrypt.sh -c -x
-
The above is all done on boxes that already has a certificate from Letsencrypt right? How about a brand new VM?
-
The above is all done on boxes that already has a certificate from Letsencrypt right? How about a brand new VM?
No idea as I have not tried it. If the issue is the same then it may be there end rather than ours but we need more data to debug it
-
I had theses errors on new issue of certificates on both SME9 and SME10.
Funny fact the box who did it the least was the one with the worst ADSL connexion, while or the other have 100 Mbps symetrical connexion at least. They are on every part of the globe ( europe, northe america and asia)
this leave me to say that this is an issue with their dns beeing hits too many times.
this might have to be reported to the dev of the script, so he can avoid curl to try to resolve it each time, when the box has already the IP.. (avoiding at least the rrror at the end of the script when you waited for validation of 70 domains it is a pain to fail for this and to have to start over.
-
I believe there are some mods/options in there to help with multi domains. You need to have a read of the docs/bugs on his git site.
If you think anything is relevant I can add options if required
-
Something I did just now on a v8 box I updated.
Errored again.
After the first error I did
wget https://acme-v01.api.letsencrypt.org/directory
It then passed that.
On the second error I did
wget http://cert.int-x3.letsencrypt.org/
Both returned OK, and then letsencrypt.sh ran fine.
No idea what the problem is though - some form of lookup issue I guess.
I need to find another box, wget BOTH URLs before starting and see what happens
-
Keep going mode in a cron job. This is now available via this commit:
https://github.com/lukas2511/letsencrypt.sh/commit/34565c193d0360dd4abbe1e630e5cad1396e81ca
I could add a key to enable/disable keep going mode (it is just adding a -g to the cron job)
Any interest ?
-
Anyone seen this before?
+ ERROR: An error occurred while sending post-request to https://acme-staging.api.letsencrypt.org/acme/new-authz (Status 403)
Details:
{
"type": "urn:acme:error:unauthorized",
"detail": "No registration exists matching provided key",
"status": 403
-
https://github.com/lukas2511/letsencrypt.sh/issues/163
-
I did, after the curl error
solution : delete the generated key to let the script to create a new one and register it completely.
-
JFYI, I reverted back to the manual method of installing and using letsencrypt. It works for me.
-
This is not Letsencrypt specific. Most browsers handle it in some way (either block mixed content, warn the user, mark the connexion as insecure)
@Daniel, how about a subdomain secured with letsencrypt? I've created a subdomain (with webapps-common) where the Document root is pointing to /opt/cloud. Trying to generate the letsencrypt for "cloud.mydomain.com" shows an error that letsencrypt was unable to verify the challenge and exits.
Thoughts?
-
@Daniel, how about a subdomain secured with letsencrypt? I've created a subdomain (with webapps-common) where the Document root is pointing to /opt/cloud. Trying to generate the letsencrypt for "cloud.mydomain.com" shows an error that letsencrypt was unable to verify the challenge and exits.
Thoughts?
Answer is in the docs.... :-)
Every domain has to be able to resolve the .well-known/acme-challenge directory
Another good reason to keep everything in ibays - my contrib does not work on other directories. If you use ibays it should work with web-apps
-
Got letsencrypt working now with '/opt/myapp' will add to the wiki.
-
Anyone seen this before?
+ ERROR: An error occurred while sending post-request to https://acme-staging.api.letsencrypt.org/acme/new-authz (Status 403)
Details:
{
"type": "urn:acme:error:unauthorized",
"detail": "No registration exists matching provided key",
"status": 403
Also note
https://github.com/lukas2511/letsencrypt.sh/issues/2
I was able to get around it by just using the -c option and removing my private key which I believe others did as well. I am moving forward now.
I have added a note on the Howto.
-
[quote link=topic=51961.msg270802#msg270802 date=1470648404]
Quote
I was able to get around it by just using the -c option and removing my private key which I believe others did as well. I am moving forward now.
[/quote]
same here! after the test I tend to delete all the created keys before switch to live and the same if I hit an error that the key is not registered following a timout during registration of private key.
-
FYI
http://m.theregister.co.uk/2016/08/18/lets_encrypt_clarifies_rate_limit_rules/
-
Looks like Mitel's integrated Let's Encrypt in what grew out of e-smith/SME Server; look at the screen shot posted here:
https://community.letsencrypt.org/t/failing-to-get-free-certificate-from-lets-encrypt-help/19648
-
Yup.... we're slow on the uptake
-
FYI
https://letsencrypt.org/stats/ (https://letsencrypt.org/stats/)
-
Well we got it working early enough :-)
-
The downside of big money...
https://github.com/lukas2511/dehydrated
Seems you can no longer call a script whatever you want.
Seems like you'll all have to avoid using feckbook.sh and microslop.pl etc now.
Sorry but this sucks.
I'll try and do a new rpm as soon as I can but it might take a few days. I'll need to think about what to call it......
B. Rgs
John
-
New RPM in my repo. Please see the wiki for notes on updating (saves me typing it twice !!)
https://wiki.contribs.org/Letsencrypt
-
thanks John for your work,
I did some change to the update in order to save the previous registration token.
also is there a kind of pre script where we could put the curl https://acme-v01.api.letsencrypt.org/directory > /dev/null and curl http://cert.int-x3.letsencrypt.org/ > /dev/null?
at least we could put this before the cron ?
-
thanks John for your work,
I did some change to the update in order to save the previous registration token.
I left the oringinals there so when you update it should only change settings once it completes successfully.
also is there a kind of pre script where we could put the curl https://acme-v01.api.letsencrypt.org/directory > /dev/null and curl http://cert.int-x3.letsencrypt.org/ > /dev/null?
at least we could put this before the cron ?
I don't think so... the second url can vary (I have seen x1 sometimes)
I think there is a deeper issue that needs investigating but am on holiday til next week. I think there may be retry options on the script, though not sure if that is our issue.
I'll look when I get back.
B. Rgds
John
-
I don't think so... the second url can vary (I have seen x1 sometimes)
Currently it should always be X3; the X1 intermediate cert has been retired, AIUI. But we will see different intermediate certs in the future, so we shouldn't hardcode URLs this way. The ACME protocol will return the URL for the intermediate cert, and I believe that's how both certbot and dehydrated (and most of the other clients) construct the "chain" and "fullchain" files.
-
I left the oringinals there so when you update it should only change settings once it completes successfully.
if you don't renew the first one you will start recieving mails to say that your cert has not been renewed which could lead to some incomprehension, so even if it is manually, it is important I think to explain how to transfer their old data to the new path.
I don't think so... the second url can vary (I have seen x1 sometimes)
for the cron we could at least add in /etc/cron.daily/letsencrypt at the beginning
curl https://acme-v01.api.letsencrypt.org >/dev/null
curl http://cert.int-x1.letsencrypt.org/ > /dev/null
curl http://cert.int-x2.letsencrypt.org/ > /dev/null
curl http://cert.int-x3.letsencrypt.org/ > /dev/null
but I am almost certain this could be added in the hook script. Just need to test if they will be launched first.
I think there is a deeper issue that needs investigating but am on holiday til next week. I think there may be retry options on the script, though not sure if that is our issue.
agreed this would be only a workaround...
the problem might more be related to the environement variable when the script is runt, as it was not able to trigger the dns service to resolve the domain, while it wors when you do this as root yourself ( curl ...)
-
On my server I host several domains, one of which (the primary) has a certificate from RapidSSL. Can I use the contrib to provide certificates for the other domains, while retaining the certificate for the primary domain?
Thanks, this certainly looks interesting
Jesper H
-
On my server I host several domains, one of which (the primary) has a certificate from RapidSSL. Can I use the contrib to provide certificates for the other domains, while retaining the certificate for the primary domain?
Not without some other fairly significant changes to SME. It's designed to use a single certificate for all hostnames. However, unless the RapidSSL cert is an EV cert, there's really no reason to keep it.
-
JPP,
Briefly (as I am still on hols)
Existing certs... I have only seen mails relating to test certs (not sure if this can be optionally disabled.... Letsencrypt decided to do this, not me or dehydrated)
If your originals are renewed correctly the old ones should become irrelevant surely ? If they are updated correctly by dehydrated the hook script (should) take care of paths.
Curl.... Hook script only works after the certs are generated, not before, so you'd either need a 'pre' hook or if you think ENV vars them something in cron or the script itself.
Either way it a bodge and not an elegant 'SME' type solution. I'll look further next week and possibly speak to the developer.
Give me a few days.
B. Rgds
JC
PS might it be better to add this contrib to CVS so it can be bugged rather than discussed here on the foros (I tend to miss a lot here) It can always be obsoleted if it gets built in to SME ?