Difference between revisions of "Setting up HTTPS using Let's Encrypt"
(Added advice that rewrite trigger should no longer bee needed) |
m |
||
Line 105: | Line 105: | ||
== Additional Notes == | == Additional Notes == | ||
− | The default EPrints Apache Rewrite handler use to decline any requests to a URL containing <code>/.</code>. This meant that the challenge/response for a Let's Encrypt certificate renewal that uses the <code>/.well-known/acme-challenge/</code> path will fail. However, this does not seems to be the case in recent | + | The default EPrints Apache Rewrite handler use to decline any requests to a URL containing <code>/.</code>. This meant that the challenge/response for a Let's Encrypt certificate renewal that uses the <code>/.well-known/acme-challenge/</code> path will fail. However, this does not seems to be the case in recent (March 2023) testing, although there has not been a specific change to stop declining <code>/.</code> requests. If you still find issues it is worth trying the advice below. |
To make this work you could add a location block to your Apache config, to ensure the <code>/.well-known/</code> are not handled by EPrints, or use an EPrints URL rewrite trigger to handle the request: | To make this work you could add a location block to your Apache config, to ensure the <code>/.well-known/</code> are not handled by EPrints, or use an EPrints URL rewrite trigger to handle the request: |
Revision as of 23:23, 28 March 2023
Manual Sections | ||
|
By default EPrints does not come setup to use HTTPS. This is because you need to generate a SSL certificate and if this is not signed by a known Certificate Authority a user's web browser is likely to complain vigorously. In the past it has typically costed a fair amount of money to obtain a SSL certificate from your hosting provider. However, now there is Let's Encrypt it is possible to get a certificate for free. This is not to say you should use Let's Encrypt in all cases. UK academic institutions should continue to obtain their SSL certificates through Jisc and other institutions/organisations may already have similar arrangements for obtaining SSL certificates.
As well as being free, Let's Encrypt has an automated way for renewing certificates. However, it should be noted that the length of its certificates is a lot shorter at just 3 months. As the renewal process is automatic, this time period is more appropriate to maximise security. Let's Encrypt's certificate generation requires your EPrints repository to be publicly accessible. Beneath are instructions on how to set up EPrints to enable HTTPS with a Let's Encrypt certificate.
1. Go to the https://certbot.eff.org/ and follow the instructions for your web server and operating system (the former will almost always be Apache) and follow the instructions provided.
2. When you get to the point of running the certbot command you want the certificate only so should type as the root user:
certbot --apache certonly
3. Take a note of the path to were your certificate, key and CA chain have been saved. This will probably be something like
/etc/letsencrypt/live/YOUR-REPOSITORY-DOMAIN/
4. If you have not already done so, create an directory called ssl inside your archive's directory, i.e.
mkdir EPRINTS_PATH/archives/REPOID/ssl/
5. Create a file inside the new ssl directory called securevhost.conf and include the following contents, amending the ServerName, SSLCertificateFile, SSLCertificateKeyFile SSLCertificateChainFile and Include as appropriate at least. You will note that this configuration also enables HTTP Strict Transport Security (HSTS) for additional security. This ensures that after the first time you visit HTTPS for a particular site in your web browser, all future HTTP requests for this hostname will automatically be converted by your browser to HTTPS.
<VirtualHost *:443>
ServerName YOUR-REPOSITORY-DOMAIN:443
# Enable HSTS
Header always set Strict-Transport-Security "max-age=63072000;"
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on
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
SSLCertificateFile /etc/letsencrypt/live/YOUR-REPOSITORY-DOMAIN/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/YOUR-REPOSITORY-DOMAIN/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/YOUR-REPOSITORY-DOMAIN/chain.pem
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
LogLevel warn
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
Include EPRINTS_PATH/cfg/apache_ssl/REPOID.conf
PerlTransHandler +EPrints::Apache::Rewrite
</VirtualHost>
6. If you have not already done so, add a configuration file at /opt/eprints3/archives/REPOID/cfg/cfg.d/15_https.pl with the following configuration:
$c->{securehost} = $c->{host};
$c->{secureport} = 443;
$c->{http_root} = undef;
7. Now you will need to regenerate the rest of your Apache configuration for EPrints with the following command run as the EPrints user. (Substitute the path as appropriate):
/opt/eprints3/bin/generate_apacheconf --system --replace
8. Apache will not yet have been setup to include the Apache configuration file you created in step 5. To include this, you will need to edit the file in your Apache configuration directory (/etc/httpd/ on RHEL/CentOS/Fedora and /etc/apache2/ on Debian/Ubuntu) and find the file that contains the line cfg/apache.conf, e.g.
cd /etc/httpd/
grep -r "cfg/apache.conf" *
9. Once you have found it you will need to edit it and add the following line, changing the path as appropriate:
Include EPRINTS_PATH/archives/REPOID/ssl/securevhost.conf
10. Now, (as root or using sudo) test that the Apache configuration is correct and fix any issues if necessary:
apachectl configtest
11. Restart Apache and check whether you can access your EPrints repository using HTTPS in a web browser:
apachectl restart
12. To ensure that the certificate get renewed when necessary enable the certbot-renew timer:
systemctl enable --now certbot-renew.timer
Additional Notes
The default EPrints Apache Rewrite handler use to decline any requests to a URL containing /.
. This meant that the challenge/response for a Let's Encrypt certificate renewal that uses the /.well-known/acme-challenge/
path will fail. However, this does not seems to be the case in recent (March 2023) testing, although there has not been a specific change to stop declining /.
requests. If you still find issues it is worth trying the advice below.
To make this work you could add a location block to your Apache config, to ensure the /.well-known/
are not handled by EPrints, or use an EPrints URL rewrite trigger to handle the request:
#this could be saved into e.g. [EPRINTS_ROOT]/lib/cfg.d/z_rewrite_url_LetsEncrypt.pl
# import Apache constant e.g. 'OK'
use EPrints::Apache::AnApache;
$c->add_trigger( EP_TRIGGER_URL_REWRITE, sub {
my( %o ) = @_;
# if the incoming request matches the LetsEncrypt challenge URL...
if( $o{uri} =~ m!^${o{urlpath}}/\.well-known/acme-challenge/! )
{
# and the LetsEncrypt renewal process has put the file in EPRINTS_ROOT/archives/ARCHIVEID/html/.well-known/acme-challenge/
if( -f $o{repository}->get_conf( "htdocs_path" ).$o{uri} )
{
# reply with an HTTP '200'
${$o{return_code}} = OK;
# and return the file reqested
$o{request}->filename( $o{repository}->get_conf( "htdocs_path" ).$o{uri} );
}
# and say that we've handled the request - so no more triggers should be run.
return EP_TRIGGER_DONE;
}
} );