Changes

From SME Server
Jump to navigationJump to search

Letsencrypt (view source)

Revision as of 21:25, 5 April 2017

6,291 bytes removed ,  21:25, 5 April 2017
Reorganize/rewrite
Line 5: Line 5:  
==Introduction==
 
==Introduction==
 
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority:  
 
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority:  
−
It’s free, automated, and open.
+
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.
−
Its main purpose is to allow people to encrypt their internet traffic by a very simple system.
  −
 
  −
The certs delivered must be renewed every 3 months.
      
As of December 2015, the Letsencrypt service is in a public beta state.  They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux.  At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period.  This may make them unsuitable for users of dynamic DNS services.  The latest information about rate limiting should be posted in [https://community.letsencrypt.org/t/beta-program-announcements/1631 this topic] at the letsencrypt.org forums.  As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.
 
As of December 2015, the Letsencrypt service is in a public beta state.  They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux.  At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period.  This may make them unsuitable for users of dynamic DNS services.  The latest information about rate limiting should be posted in [https://community.letsencrypt.org/t/beta-program-announcements/1631 this topic] at the letsencrypt.org forums.  As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.
   −
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose.  Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Happy hacker CA", but it will allow you to validate the toolchain and workflow.  To do this, add "--server https://acme-staging.api.letsencrypt.org/directory" to the letsencrypt commands below.  See [https://community.letsencrypt.org/t/testing-against-the-lets-encrypt-staging-environment/6763/1 this post] at the letsencrypt.org forums for more information.
+
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose.  Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Happy hacker CA", but it will allow you to validate the toolchain and workflow.
    
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].
 
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].
   −
At this time (January 2016), a contrib is under active development using the letsencrypt.sh script.  See [http://bugs.contribs.org/show_bug.cgi?id=8676 Bug 8276] and the [https://github.com/reetp/smeserver-letsencrypt/tree/smeserver-letsencrypt-0.1 GitHub page] for further information.
+
Multiple clients are available for the Letsencrypt services.  The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install.  It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.
    
==Prerequisites==
 
==Prerequisites==
Line 29: Line 26:     
Make sure you've got this all set up correctly before continuing.
 
Make sure you've got this all set up correctly before continuing.
 +
 +
==Preparation==
    
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:
 
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:
Line 40: Line 39:  
If this shows any values for crt, key, or CertificateChainFile, make a note of them.  If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:
 
If this shows any values for crt, key, or CertificateChainFile, make a note of them.  If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:
 
  config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"
 
  config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"
−
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):
  −
config show > "/root/db_configuration_backup_$(date +%Y%m%d_%H%M%S)"
     −
== Installation ==
+
==Contrib Installation of Dehydrated==
−
Multiple clients are available for the Letsencrypt services.  The official client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install.  It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.
+
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system.  This is the simplest way to install dehydrated on your SME Server.
 +
 
 +
===Installation===
 +
You'll first need to add the "ReetP" yum repository:
 +
{{:reetspetit}}
 +
Then apply changes
 +
signal-event yum-modify
 +
 
 +
You can then install the contrib using this command:
 +
yum install smeserver-letsencrypt --enablerepo=reetp
 +
signal-event post-upgrade && signal-event reboot
 +
 
 +
===Configuration===
 +
There are several configuration database entries that need to be made in order to set up this contrib.  Most of them tell the scripts which hostnames need to be part of your certificate.
 +
 
 +
====Hosts and domains for the certificate===
 +
This contrib will obtain a single certificate from Let's Encrypt.  The certificate will include all the domains and hostnames that:
 +
* Are configured on your SME Server (e.g., through the Server Manager), and
 +
* Are configured to use Let's Encrypt.
   −
=== Contrib install of Dehydrated ===
+
For example, your SME Server may contain the following domains and hostnames:
−
Dehydrated is a lightweight alternative ACME client which will allow you to retrieve certificates from the Letsencrypt servers without needing to install any additional software on your server.
     −
The script has now been imported into the contribs repository and can be installed as follows:
+
* domain1.com
 +
  * www.domain1.com
 +
  * mail.domain1.com
 +
  * ftp.domain1.com
 +
* domain2.com
 +
  * www.domain2.com
 +
  * mail.domain2.com
 +
 
 +
For each DOMAIN that you want to be included in the certificate, run this command:
 +
db domains setprop $DOMAIN letsencryptSSLcert enabled
 +
 
 +
Using the above example, one invocation of the command would look like this:
 +
db domains setprop domain1.com  letsencryptSSLcert enabled
 +
 
 +
For each HOSTNAME that you want to be included in the certificate, run this command:
 +
db hosts setprop $HOSTNAME letsencryptSSLcert enabled
 +
 
 +
Using the above example, one invocation of the command would look like this:
 +
db hosts setprop www.domain1.com letsencryptSSLcert enabled
 +
 
 +
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames.
 +
config setprop letsencrypt configure all | domains | hosts
 +
 
 +
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc.  Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com.  Setting this property to "all" will include all domain names and hostnames in the certificate.
 +
 +
====Other configuration properties====
 +
No other settings are mandatory.  However, it's recommended to configure an email address.  If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this.  Do so with this command:
 +
config setprop letsencrypt email admin@domain1.com
 +
 
 +
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.
 +
 
 +
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits.  This should not be necessary in most cases, but if desired, use this command to do so:
 +
config setprop letsencrypt keysize NUMBER
 +
 
 +
===Enable Test Mode===
 +
The next step is to enable test mode.  This will obtain certificates from the staging server.  The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate.  Enable test mode using this command:
 +
config setprop letsencrypt status test
 +
signal-event console-save
 +
 
 +
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates.  To do this, run
 +
dehydrated -c
 +
 
 +
If this runs without errors, try to connect to your server-manager page.  You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal.  However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days.  If this was successful, proceed to production.
 +
 
 +
===Enable Production Mode===
 +
Once you've successfully tested your installation, set it to production mode using these commands:
 +
config setprop letsencrypt status enabled
 +
signal-event console-save
 +
 +
Then obtain a new certificate from the Let's Encrypt production server:
 +
dehydrated -c -x
 +
 
 +
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.
 +
 
 +
If this command succeeded, congratulations!  You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity.
 +
 
 +
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.
 +
 
 +
==Manual Installation of Dehydrated==
 +
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script.  It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client.  If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.
 +
 
 +
===Contrib install of Dehydrated===
 +
The dehydrated script has been imported into the contribs repository and can be installed as follows:
    
  yum --enablerepo=smecontribs install dehydrated
 
  yum --enablerepo=smecontribs install dehydrated
   −
By itself the script will do absolutely nothing and requires configuration files to be created and the script called either manually or via cron.
+
The script must be configured as described below.
−
 
     −
=== Git install of latest version ===
+
===Git install of latest version===
   −
If you need the latest version of the script then you can remove the contrib above and manually install as follows:
+
If you need or want the absolute latest version of the script then you can manually install as follows:
    
Begin by installing git:
 
Begin by installing git:
Line 68: Line 143:  
  mv dehydrated/dehydrated /usr/local/bin/
 
  mv dehydrated/dehydrated /usr/local/bin/
   −
=== Manual Configuration of Dehydrated ===
+
===Manual Configuration of Dehydrated===
    
You'll need to create two configuration files for Dehydrated.
 
You'll need to create two configuration files for Dehydrated.
−
  cd dehydrated
+
  cd /etc/dehydrated
 
  mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
  mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
  nano -w domains.txt
 
  nano -w domains.txt
Line 90: Line 165:  
  # E-mail to use during the registration (default: <unset>)
 
  # E-mail to use during the registration (default: <unset>)
 
  CONTACT_EMAIL="admin@yourdomain.com"
 
  CONTACT_EMAIL="admin@yourdomain.com"
 +
 
Ctrl-X to exit, Y to save.
 
Ctrl-X to exit, Y to save.
   Line 107: Line 183:  
   /sbin/e-smith/db configuration setprop modSSL crt $CERT
 
   /sbin/e-smith/db configuration setprop modSSL crt $CERT
 
   /sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN
 
   /sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN
−
   /sbin/e-smith/signal-event domain-modify
+
   /sbin/e-smith/signal-event ssl-update
−
  /sbin/e-smith/signal-event email-update
  −
  /sbin/e-smith/signal-event ibay-modify
   
  fi
 
  fi
−
  −
If you have at least version 5.6.0-26 of e-smith-base installed (i.e., if you've installed updates since late January of 2016), replace the three signal-event lines with
  −
  −
  /sbin/e-smith/signal-event ssl-update
      
Ctrl-X to exit, Y to save.  Then make it executable:
 
Ctrl-X to exit, Y to save.  Then make it executable:
Line 139: Line 209:  
and make sure there are values set for crt, key, and CertificateChainFile.
 
and make sure there are values set for crt, key, and CertificateChainFile.
   −
As above, once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.
+
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run
 +
dehydrated -c -x
   −
== Production Mode ==
+
to obtain trusted a trusted certificate.
 +
 
 +
===Renewal===
 +
When run, the dehydrated script will check your existing certificate to see how long it's valid.  If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates.  If more than 30 days remain, the script will exit without further action.  All that's necessary is to run dehydrated daily:
 +
nano -w /etc/cron.daily/call-dehydrated
 +
 
 +
Enter the following in this file:
 +
#!/bin/bash
 +
/usr/local/bin/dehydrated -c
 +
Ctrl-X to exit, Y to save.  Then make it executable:
 +
chmod +x /etc/cron.daily/call-dehydrated
    +
==Requiring SSL==
 +
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections.  For any i-bays, you can do this using the server-manager page, or using a shell command.  For the Primary i-bay, you'll need to use the shell command:
 +
db accounts setprop {accountname} SSL enabled
 +
or
 +
db accounts setprop Primary SSL enabled
 +
 +
==Backup==
 +
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines.  Make sure to add this directory to your backups.  See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature.  If using Affa for backup, add
 +
Include=/etc/dehydrated
   −
{{Warning box|Once your configuration is set, you need switch to production mode.<br>}}
+
to the Affa configuration file.
−
So remove the test certificate with<br>
  −
  rm -rf /etc/dehydrated/certs/<br>
  −
Comment out again the CA line on file '''/etc/dehydrated/config'''  so it appears like:<br>
  −
# CA="https://acme-staging.api.letsencrypt.org/directory"<br>
  −
and re-run the script<br>
  −
dehydrated -c<br>
      
== Troubleshooting ==
 
== Troubleshooting ==
−
 
+
===Certificate Errors===
 
Errors in the certificate files may prevent Apache and some other services from starting.  If you previously had custom settings for modSSL, revert those with:
 
Errors in the certificate files may prevent Apache and some other services from starting.  If you previously had custom settings for modSSL, revert those with:
 
  config setprop modSSL crt (old value)
 
  config setprop modSSL crt (old value)
Line 168: Line 252:  
  signal-event reboot
 
  signal-event reboot
   −
== Renewal of the certificates ==
+
===Authorization Errors===
−
As part of the security of Dehydrated the certificates must be renewed every 3 months.  The process will differ depending on whether you're using the official client or Dehydrated.
  −
 
  −
=== Using Dehydrated ===
  −
When run, the dehydrated script will check your existing certificate to see how long it's valid.  If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates.  If more than 30 days remain, the script will exit without further action.  All that's necessary is to run dehydrated daily:
  −
nano -w /etc/cron.daily/call-dehydrated
  −
 
  −
Enter the following in this file:
  −
#!/bin/bash
  −
/usr/local/bin/dehydrated -c
  −
Ctrl-X to exit, Y to save.  Then make it executable:
  −
chmod +x /etc/cron.daily/call-dehydrated
  −
 
  −
== Backup ==
  −
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines.  Make sure to add this directory to your backups.  See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature.
  −
 
  −
== Creating certificates for internal servers ==
  −
{{Warning box|These procedures need to be revised to work with letsencrypt.sh}}
  −
You may have one or more internal servers on your network for which you want or need trusted TLS certificates, but which aren't directly accessible from the outside.  The Letsencrypt service can handle this too, although the process isn't quite as simple as shown above.
  −
 
  −
Assumptions:
  −
* You've followed the instructions above to install the Letsencrypt client, and it's working
  −
* The hostname for which you need a certificate resolves, from the outside, to your SME Server.  For example, you've registered yourdomain.tld, and a DNS record for *.yourdomain.tld points to your SME Server.  You want to create a certificate for privateserver.yourdomain.tld
  −
* Port 80 on your SME Server is open to the Internet--you aren't behind a firewall, or some ISP filtering, that would block it.
  −
 
  −
You can either create the certificate on your SME Server, and then copy it to the internal server using whatever means that server provides; or (if the internal server is able to run the Letsencrypt client) you can generate the certificate on the internal server.
  −
 
  −
=== Generate the certificate on the SME Server ===
  −
You could simply follow the instructions above, using the FQDN of your internal server.  However, those instructions require that you take down your web server briefly.  If you were generating a new certificate for the SME Server, you'd need to do this anyway, so that the web server would load the new certificate.  If you're generating a certificate for a different internal server, though, you may not want (and you do not need) to take down your SME Server's web server.
  −
 
  −
Follow the instructions above to create the certificate, but replace the letsencrypt command line with:
  −
./letsencrypt-auto certonly --webroot --webroot-path /home/e-smith/files/ibays/Primary/html \
  −
  --email admin@yourdomain.tld -d privateserver.yourdomain.tld
  −
 
  −
The Letsencrypt client will run and place the certificate files in /etc/letsencrypt/live/privateserver.yourdomain.tld/ on your SME Server.  You can then copy them to your internal server and install them using whatever mechanism that server provides.  This will not alter the configuration of your SME Server.
  −
 
  −
Once the certificate files are created, installing them on the internal server can be automated.  One possible way to do this is to first ensure that the root user on your SME server has an [[SSH Public-Private Keys|SSH public key]] generated, that key does not have a passphrase assigned, and that key is trusted by the root user on your internal server.  Then, you can add the following to your renewal script:
  −
 
  −
/opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --webroot \
  −
  --webroot-path /home/e-smith/files/ibays/Primary/html --email admin@yourdomain.tld \
  −
  -d privateserver.yourdomain.tld
  −
  −
export CERTDIR="/etc/letsencrypt/live/privateserver.yourdomain.tld"
  −
scp $CERTDIR/cert.pem root@privateserver:/etc/pki/tls/certs/privateserver.yourdomain.tld.crt
  −
scp $CERTDIR/privkey.pem root@privateserver:/etc/pki/tls/private/privateserver.yourdomain.tld.key
  −
scp $CERTDIR/chain.pem root@privateserver:/etc/pki/tls/certs/server-chain.crt
  −
ssh root@privateserver /sbin/service httpd restart
  −
 
  −
You will, of course, need to modify the paths on the internal server to be consistent with where that server expects the certificate files to be; the paths above are applicable to a CentOS-based server.
  −
 
  −
=== Generate the certificate on the internal server ===
  −
If the internal server is Unix-y and otherwise meets the requirements for the Letsencrypt client, you can run the client on the internal server using manual domain authentication.  This will require you to create a small file on your SME Server, which you can delete once the certificate is created.
  −
 
  −
The letsencrypt command would look like:
  −
./letsencrypt-auto certonly --manual --email admin@yourdomain.tld -d privateserver.yourdomain.tld
  −
 
  −
When the Letsencrypt client runs, it will show you a challenge like the following, with different random strings:
  −
Make sure your web server displays the following content at
  −
http://privateserver.yourdomain.tld/.well-known/acme-challenge/U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc before continuing:
  −
  −
U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc.oYz0Q5G7t8oAAhKBGu6Y9InuE1eP2CRhR-RtUVXvloc
  −
 
  −
At this point, on your SME Server, you'll need to create that file:
  −
# mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
  −
# echo U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc.oYz0Q5G7t8oAAhKBGu6Y9InuE1eP2CRhR-RtUVXvloc > /home/e-smith/files/primary/html/.well-known/acme-challenge/U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc
  −
 
  −
Then press the Enter key on your internal server.  As of this writing (10 Dec 2015), the client has a bug which reports "Self-verify of challenge failed", but it will create the certificates anyway (and it will correctly tell you that they're created).  Once the client finishes and tells you the certificates are created, you can delete the nonce from your SME Server:
  −
# rm /home/e-smith/files/primary/html/.well-known/acme-challenge/U8AGPrh8wTM9wYpaOGUmfihZezzoLrCAhspJYeO-lsc
  −
 
  −
The certificate files will be in /etc/letsencrypt/live/privateserver.yourdomain.tld/ on your internal server.
  −
 
  −
 
  −
==Install with John Crisp contrib==
  −
{{Note box |Due to the change of names from Letsencrypt.sh to Dehydrated I have made a new contrib 0.3-1 See notes below}}
  −
 
  −
Sources: https://github.com/reetp/smeserver-letsencrypt
  −
 
  −
First add his repo
  −
{{:reetspetit}}
  −
Then apply changes
  −
signal-event yum-modify
  −
 
  −
Then install
  −
yum install smeserver-letsencrypt --enablerepo=reetp
  −
 
  −
 
  −
Set email
  −
  config setprop letsencrypt email my@email.com
  −
 
  −
 
  −
TEST FIRST
  −
db configuration setprop letsencrypt status test
  −
 
  −
ENABLE SOME HOSTS Or DOMAINS for testing purposes
  −
db hosts setprop www.mydomain.com letsencryptSSLcert enabled
  −
db domains setprop mydomain.com  letsencryptSSLcert enabled
  −
 
  −
Then run
  −
 
  −
signal-event console-save
  −
service dnscache restart
  −
 
  −
Create test certificates (file is in the path so should be OK)
  −
 
  −
dehydrated -c -x
  −
 
  −
Once you are satisfied with your test
  −
 
  −
config setprop letsencrypt status enabled
  −
signal-event console-save
  −
  −
 
  −
and
  −
 
  −
rm /etc/dehydrated/certs/* -rf
  −
rm /etc/dehydrated/accounts/* -rf
  −
dehydrated -c -x
  −
 
  −
Note thereafter you ONLY need to run
  −
 
  −
dehydrated -c
  −
 
  −
 
  −
=== What is next ?===
  −
If you make any db key changes run console-save to regenerate your config files
  −
 
  −
You can now set any public ibays to SSL only using the server manager, or set the following key
  −
 
  −
db accounts setprop {accountname} SSL enabled
  −
 
  −
You cannot set the Primary ibay to SSL from the panel
  −
 
  −
db accounts setprop Primary SSL enabled
  −
 
  −
signal-event console-save
  −
service dnscache restart
  −
 
  −
or
  −
 
  −
signal-event ibay-modify Primary
  −
 
  −
=== Other info ===
  −
Optional keys - (not required)
  −
 
  −
config setprop letsencrypt email (defaults to empty)
  −
config setprop letsencrypt keysize (defaults to 4096)
  −
 
  −
If the licence changes before this script is updated you can specify a new licence URL
  −
config setprop letsencrypt licence https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf
  −
 
  −
You can enable just a domain or just a host on a domain
  −
 
  −
Per domain
  −
 
  −
db domains setprop mydomain.com letsencryptSSLcert enabled
  −
 
  −
Per host
  −
 
  −
db hosts setprop www.mydomain.com letsencryptSSLcert enabled
  −
 
  −
If you want a hook script to push changes remotely (not required)
  −
 
  −
db configuration setprop letsencrypt hookScript enabled
  −
db configuration setprop letsencrypt user someuser
  −
db configuration setprop letsencrypt host 1.2.3.4 db configuration setprop letsencrypt path //some/remote/local/path
  −
 
  −
You can now use a db entry to set all domains or hosts regardless of status
  −
 
  −
config setprop letsencrypt configure 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.
  −
 
  −
===Problems===
   
The first thing is to check all your domains can resolve
 
The first thing is to check all your domains can resolve
   Line 363: Line 271:  
Then run letsencrypt again
 
Then run letsencrypt again
   −
  dehydrated -c -x
+
  dehydrated -c
−
 
  −
{{Note box | If you make too many failed attempts at certificate generation you will be locked out of the letsencrypt servers for up to a week. Make sure everything works in test mode before you try it for real! See notes on rate limits below}}
      
To restore the original certificates:
 
To restore the original certificates:
Line 374: Line 280:     
  signal-event console-save
 
  signal-event console-save
−
  −
===Affa===
  −
  −
If you have a Letsencrypt certificate on the server you are backing up, then you should also include
  −
Include=/etc/dehydrated
  −
  −
in Affa config file.
      
===Errors===
 
===Errors===
Line 400: Line 299:  
https://letsencrypt.org/docs/rate-limits/
 
https://letsencrypt.org/docs/rate-limits/
   −
===Upgrade to the dehydrated script===
  −
The old letsencrypt.sh script has been renamed to dehydrated
  −
  −
To upgrade please do the following:
  −
  −
yum --enablerepo=reetp install smeserver-letsencrypt
  −
  −
signal-event post-upgrade; signal-event reboot
  −
  −
alternatively, this should do the same if you do not want to reboot:
  −
  −
signal-event console-save
  −
  −
if you want to keep the same registration
  −
cp -r /etc/letsencrypt.sh/accounts /etc/dehydrated/
  −
cp -r /etc/letsencrypt.sh/certs /etc/dehydrated/
  −
  −
After the reboot you can then run the following to make new certificates:
  −
  −
dehydrated -c -x
  −
  −
I have sometime found that I get connection errors after installation as follows.
  −
  −
If you receive the following error:
  −
  −
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
  −
  −
cd ~
  −
curl https://acme-v01.api.letsencrypt.org/directory
  −
dehydrated -c -x
  −
  −
If you then get an error like this:
  −
  −
ERROR: Problem connecting to server (get for http://cert.int-x3.letsencrypt.org/; curl returned with 6)
  −
  −
cd ~
  −
curl http://cert.int-x3.letsencrypt.org/ > /dev/null
  −
dehydrated -c -x
  −
  −
Check that the new certificates have been added to the modSSL key:
  −
  −
config show modSSL
  −
  −
modSSL=service
  −
    CertificateChainFile=/etc/dehydrated/certs/yourdomain.com/chain.pem
  −
    TCPPort=443
  −
    access=public
  −
    crt=/etc/dehydrated/certs/yourdomain.com/cert.pem
  −
    key=/etc/dehydrated/certs/yourdomain.com/privkey.pem
  −
    status=enabled
  −
  −
==Source from info==
  −
Source: http://forums.contribs.org/index.php/topic,51961.msg266680.html#msg266680
   
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]
 
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]
 
[[Category: Administration:Certificates]]
 
[[Category: Administration:Certificates]]
DanB35
147

edits

Retrieved from "https://wiki.koozali.org/Special:MobileDiff/33136"

Navigation menu