6

I have a few sites running with a StartSSL free certificate (CJSHayward.com, JobhuntTracker.com), and Firefox rejects StartSSL and displays an error page saying that my server is not properly configured (IIRC) because of the certificate chain. I asked for help and confirmed that my VirtualHost (available on request) was for the certificate chain and I had the intermediate certificate installed correctly. The sites are displayed without errors that I am aware of in Chrome, Safari, Edge, or Opera.

After some searching, Let's Encrypt! looked like an attractive offering, and before too long I had (AFAICT) a private key and a certificate for each domain under /etc/apache2/sites-enabled, minus of course any domains that are no longer mine. I thought I'd do a trial run and make an HTTPS connection to a site now available only under HTTP: JSH.name. I moved the "Let's Encrypt!" certificate and private key to my SSL directory and added:

<VirtualHost *:443> ServerAdmin [email protected] DocumentRoot /home/jonathan/stornge SSLEngine On SSLCertificateFile /etc/apache2/ssl/0000_csr-letsencrypt.pem SSLCertificateKeyFile /etc/apache2/ssl/0000_key-letsencrypt.pem ServerName jsh.name ServerAlias www.jsh.name LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined CustomLog /home/jonathan/logs/stornge.com combined <Directory /home/jonathan/stornge/> Options ExecCGI Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> </VirtualHost>

Then I rebooted to see my work, and every HTTP or HTTPS request I made simply hung. This included two domains on HTTPS with my StartSSL certificate, and the domain that should have been newly available on HTTPS accessed via both HTTP and HTTPS. I commented out the VirtualHost and bounced Apache, and all of the old functionality was back again in working order.

Have I used Let's "Encrypt!" correctly? I'm slightly suspicious as existing SSL configuration has private keys with an extension of .key, a certificate extension of .crt, and a certificate chain file with extension .pem.

I tried again after checking the SSL directory and finding that 0000_csr.letsencrypt.pem was mode 644; I changed all files in that directory to mode 600. When I tried a moment ago, I got a repeat of the old behavior: the website hangs on all requests and, in addition, an apachectl restart gets a statement (I forget the exact wording) that httpd is not running and the computer is trying to start it.

How can I get working free certitificates for "Let's Encrypt" or some other tool that hasn't alienated Firefox?

An apachectl -v gives:

Server version: Apache/2.4.10 (Debian) Server built: Nov 28 2015 14:05:48

A uname -a gives:

Linux www 4.4.0-x86_64-linode63 #2 SMP Tue Jan 19 12:43:53 EST 2016 x86_64 GNU/Linux

--UPDATE--

Contents deleted, 0000_key-letsencrypt.pem is bounded by:

-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----

A find on the directory heirarchy yields:

root@www:/etc/letsencrypt# find `pwd` -print /etc/letsencrypt /etc/letsencrypt/keys /etc/letsencrypt/keys/0000_key-letsencrypt.pem /etc/letsencrypt/accounts /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/1ef8dc9b994b9b68a4e9c7cedd003be3 /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/1ef8dc9b994b9b68a4e9c7cedd003be3/private_key.json /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/1ef8dc9b994b9b68a4e9c7cedd003be3/meta.json /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/1ef8dc9b994b9b68a4e9c7cedd003be3/regr.json /etc/letsencrypt/renewal /etc/letsencrypt/options-ssl-apache.conf /etc/letsencrypt/csr /etc/letsencrypt/csr/0000_csr-letsencrypt.pem

The directory /home/jonathan/stornge and its contents are world readable and world executable where that would make a difference.

--UPDATE--

Adding something substantive here:

The http://OrthodoxChurchFathers.com Apache conf file has two VirtualHosts, one to serve up http://OrthodoxChurchFathers.com and one to redirect http://www.OrthodoxChurchFathers.com requests to http://OrthodoxChurchFathers.com. The .conf file housing both VirtualHosts is:

<VirtualHost *:80> ServerAdmin webmaster@localhost ServerName orthodoxchurchfathers.com #ServerAlias www.orthodoxchurchfathers.com fathers.jonathanscorner.com
 
DocumentRoot /home/cjsh/fathers/document_root &lt;Directory /> Options FollowSymLinks AllowOverride None &lt;/Directory> &lt;Directory /home/cjsh/fathers> Options ExecCGI FollowSymLinks Indexes MultiViews AllowOverride None Order allow,deny allow from all &lt;/Directory> DirectoryIndex index.cgi index.html ErrorLog ${APACHE_LOG_DIR}/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined Alias /doc/ "/usr/share/doc/" &lt;Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 &lt;/Directory> 
 
</VirtualHost>
 
&lt;VirtualHost *:80> ServerAdmin [email protected] ServerName www.orthodoxchurchfathers.com ServerAlias fathers.jonathanscorner.com DocumentRoot /home/cjsh/oldmirror RewriteEngine On RewriteRule ^(.*)$ http://orthodoxchurchfathers.com$1 [R=301,L] &lt;/VirtualHost></pre></code> 
 
When I try to run it and request orthodoxchurchfathers.com alone, I get:
 ┌──────────────────────────────────────────────────────────────────────┐ │ We were unable to find a vhost with a ServerName or Address of │ │ orthodoxchurchfathers.com. │ │ Which virtual host would you like to choose? │ │ (note: conf files with multiple vhosts are not yet supported) │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │1 008-stornge.conf | Multiple Names | │ │ │ │2 014-paraskeva.conf | paraskeva.jonathansco | │ │ │ │3 036-unixytalk.conf | unixtalk.jsh.name | │ │ │ │4 038-proxy.conf | Multiple Names | │ │ │ │5 027-anna.conf | Multiple Names | │ │ │ │6 044-jobhunt-tracker.creation.c | Multiple Names | │ │ │ │7 049-jsh.conf | Multiple Names | │ │ │ │8 001-steampunk.conf | | │ │ │ │9 006-blajeny.conf | Multiple Names | │ │ │ │10 032-videos.conf | Multiple Names | d│ │ │ └────↓(+)──────────────────────────────────────────────────30%─────┘ │ ├──────────────────────────────────────────────────────────────────────┤ │ │ └──────────────────────────────────────────────────────────────────────┘

The command I used was with ./letsencrypt-auto --debug certonly.

Improve this question
2
  • 5
    The filename 0000_csr-letsencrypt.pem suggests you included the certificate signing request, not the actual signed certificate. Every file you need should be in a subdirectory of /etc/letsencrypt/live with your domain name. and a serial number, you don't need anything from /etc/letsencrypt/csr or keys Do you have log file entries? Commented Mar 21, 2016 at 18:11
  • does apache have rights to read /home/jonathan/stornge? Commented Mar 29, 2016 at 13:45

3 Answers 3

Reset to default
4

I have written a pair of how-tos for running Let's Encrypt SSL certs on CentOS: initial setup & cronning it.

And my per-domain (I use the file naming convention of z-<[sub-]domain-tld>.conf) Apache config files look like this:

<VirtualHost *:80> ServerName domain.tld Redirect permanent / https://domain.tld/ </VirtualHost> <VirtualHost *:443> SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/fullchain.pem DocumentRoot /var/www/domain ServerName domain.tld ErrorLog logs/domain-error_log CustomLog logs/domain-access_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ServerAdmin [email protected] SSLEngine on <Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars </Files> <Directory "/var/www/cgi-bin"> SSLOptions +StdEnvVars </Directory> SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 <Directory "/var/www/domain"> Options All +Indexes +FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>

And my ssl.conf looks like this:

#SSL options for all sites Listen 443 SSLPassPhraseDialog builtin SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 300 Mutex sysvsem default SSLRandomSeed startup file:/dev/urandom 1024 SSLRandomSeed connect builtin SSLCryptoDevice builtin SSLCompression off SSLHonorCipherOrder on SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

Using Let's Encrypt to get SSL certs (and get your site up to an "A" rating from SSL Labs) is pretty straight-forward - once you get past some of the arcana of the Apache configs and LE command-line arguments.

Improve this answer
5
  • Thank you; may I suggest a revision to your HOWTO? Let's Encrypt doesn't do multiple VirtualHosts in one .conf file; you might add a step before Let's Encrypt looks through the .conf files that any domain or subdomain served by Let's Encrypt should have only its VirtualHost in the .conf file, and files with multiple VirtualHosts should be separated so that Let's Encrypt finds one VirtualHost, one .conf file for every domain where you address encryption. (This includes a file that has a real site at domain.tld and with it a VirtualHost redirecting www.domain.tld to the real location.) Commented Apr 6, 2016 at 17:58
  • @JonathanHayward - I run Let's Encrypt in --standalone certonly mode (see my cronning how-to (~/letsencrypt/letsencrypt-auto --agree-tos --keep --rsa-key-size 2048 --standalone certonly -m [email protected] -d domain.tld [-d sub.domain.tld [-d ...]])), I don't use any of the plugins (like automatically scanning Apache configs), which I cover in both how-tos. I appreciate the suggestion, but am having good success in standalone mode and letting it update certs behind the scenes, so to speak. Commented Apr 6, 2016 at 18:46
  • Ok, but I was writing out of difficulties with standalone certonly. I didn't use automatic scanning. Commented Apr 6, 2016 at 18:48
  • @JonathanHayward - what issues have you had with --standalone certonly? Commented Apr 6, 2016 at 18:49
  • 1
    Thank you; see the updated question. I've also posted a question at serverfault.com/questions/768643/… , which is related but separate and I did not want to tack it on to an already verbose question. Commented Apr 6, 2016 at 20:45
1

I've found the client ACME works well, it's easy to set up and get going, it's updated regularly and is easy to update, and it works very well on Amazon Linux. I've written a tutorial on it which you can find here.

Get started by downloading ACME and setting it up

https://github.com/hlandau/acme.git cp ./acmetool /usr/local/bin /usr/local/bin/acmetool quickstart

Request a certificate

./acmetool want example.com www.example.com

This is how I set up the directory for the challenge - this is where Let's Encrypt connects to your server to validate 

mkdir -p /var/www/acme-challenge/.well-known/acme-challenge chmod -R user:www-data /var/www/acme-challenge/* find /var/www/acme-challenge/ -type d -exec chmod 755 {} \; vi /var/www/acme-challenge/.well-known/acme-challenge/text.html (add "hello world!" or similar)

There's more detail and commentary on the linked website above, and the author and community are helpful.

Improve this answer
1

I had good success using EFF's Certbot in web root mode (because the idea of an automated process stopping the web server, even if only briefly, during certificate renewal scares me).

First, install Certbot. If you are on Debian Jessie (which is current at the time of my writing this), first add the jessie-backports repository, then

$ sudo apt-get install python-certbot-apache -t jessie-backports

This will bring in a handful of packages plus certbot itself.

Then, to create a certificate in webroot mode, run something like

$ sudo certbot certonly --webroot -w /srv/www/www.example.net/htdocs -d www.example.net

You can optionally add --register-unsafely-without-email as well as --rsa-key-size X if you want a modulus size other than the default (which is currently 2048 bits). -d fqdn.example.com can be repeated an arbitrary number of times, as can -w; each -w starts a new set of domains served out of a directory, domains named by -d. Let's Encrypt does not issue wildcard certificates (this is mentioned in their FAQ) and apparently, also not certificates for Punycode domain names.

The user that certbot runs as needs, at the very least and by default, write access to several places under /etc/letsencrypt. It's probably easiest to just run it as root. It will create a file under .well-known/acme-challenge under the given web root directory (-w), have the remote system verify that it's accessible over the specified domain names over HTTP, and if everything checks out will create a bunch of PEM files in /etc/letsencrypt/archive/www.example.net plus a corresponding set of symbolic links in /etc/letsencrypt/live/www.example.net and print a friendly success message.

If everything checks out, what's left for you to do is to set up your web server to use the certificate found in the host name subdirectory of /etc/letsencrypt/live for HTTPS for the domain in question. The absolute bare minimum for this for Apache is something similar to:

<VirtualHost *:443> ServerName www.example.net SSLEngine on SSLCertificateKeyFile /etc/letsencrypt/live/www.example.net/privkey.pem SSLCertificateFile /etc/letsencrypt/live/www.example.net/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/www.example.net/chain.pem </VirtualHost>

Add any other directives as desired, verify using apache2ctl -S and apache2ctl configtest that everything checks out, and activate the HTTPS virtual host with apache2ctl graceful.

Don't forget to renew the certificate regularly; currently, Let's Encrypt certificates expire after 90 days. The Debian package ships with a cron job in /etc/cron.d/certbot and a systemd service in /lib/systemd/system/certbot.service which take care of this, or you can run certbot renew manually. Remember to apache2ctl graceful to start using the newly issued certificate; you may want to adjust the cron job or systemd service to do this automatically. To automatically load renewed certificates into Apache on Debian Jessie, consider updating /lib/systemd/system/certbot.service to add to the [Service] section (note: the order is important):

ExecStartPost=/usr/sbin/apache2ctl configtest ExecStartPost=/usr/sbin/apache2ctl graceful

Doing so will automatically load the renewed certificate if the Apache configuration files pass configtest, and list Certbot as a failed unit if the configtest or graceful fails.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.