{"id":680,"date":"2017-02-25T09:38:18","date_gmt":"2017-02-25T07:38:18","guid":{"rendered":"https:\/\/helia.ee\/koolitus\/?page_id=680"},"modified":"2017-03-20T00:27:15","modified_gmt":"2017-03-19T22:27:15","slug":"how-to-secure-apache-with-lets-encrypt-on-debian-8","status":"publish","type":"page","link":"https:\/\/helia.ee\/koolitus\/?page_id=680","title":{"rendered":"How To Secure Apache with Let&#8217;s Encrypt on Debian 8"},"content":{"rendered":"<div class=\"container tutorial-header\">\n<h1 class=\"content-title Tutorial-header\">How To Secure Apache with Let&#8217;s Encrypt on Debian 8<\/h1>\n<\/div>\n<div class=\"content-body tutorial-content\" data-growable-markdown=\"\">\n<h3 id=\"introduction\">Introduction<\/h3>\n<p>This tutorial will show you how to set up a TLS\/SSL certificate from <a href=\"https:\/\/letsencrypt.org\/\">Let&#8217;s Encrypt<\/a> on a Debian 8 server running Apache as a web server. We will also cover how to automate the certificate renewal process using a cron job.<\/p>\n<p>SSL certificates are used within web servers to encrypt the traffic between the server and client, providing extra security for users accessing your application. Let&#8217;s Encrypt provides an easy way to obtain and install trusted certificates for free.<\/p>\n<h2 id=\"prerequisites\">Prerequisites<\/h2>\n<p>In order to complete this guide, you will need a Debian 8 server with a non-root <code>sudo<\/code> user for administrative tasks. You can set up a user with the appropriate permissions by following our <a href=\"https:\/\/www.digitalocean.com\/community\/tutorials\/initial-server-setup-with-debian-8\">Debian 8 initial server setup guide<\/a>.<\/p>\n<p>You must own or control the registered domain name that you wish to use the certificate with. If you do not already have a registered domain name, you may register one with one of the many domain name registrars out there (e.g. Namecheap, GoDaddy, etc.).<\/p>\n<p>If you haven&#8217;t already, be sure to create an <strong>A Record<\/strong> that points your domain to the public IP address of your server (if you are using DigitalOcean&#8217;s DNS, you can follow <a href=\"https:\/\/www.digitalocean.com\/community\/tutorials\/how-to-set-up-a-host-name-with-digitalocean\">this guide<\/a>). This is required because of how Let&#8217;s Encrypt validates that you own the domain it is issuing a certificate for. For example, if you want to obtain a certificate for <code>example.com<\/code>, that domain must resolve to your server for the validation process to work. Our setup will use <code>example.com<\/code> and <code>www.example.com<\/code> as the domain names, so <strong>both DNS records are required<\/strong>.<\/p>\n<p>When you are ready to move on, log into your server using your sudo account.<\/p>\n<h2 id=\"step-1-install-certbot-the-let-39-s-encrypt-client\">Step 1: Install Certbot, the Let&#8217;s Encrypt Client<\/h2>\n<p>The first step to using Let&#8217;s Encrypt to obtain an SSL certificate is to install the <code>certbot<\/code> Let&#8217;s Encrypt client on your server.<\/p>\n<p>The <code>certbot<\/code> package was not available when Debian 8 was released. To access the <code>certbot<\/code> package, we will have to enable the Jessie backports repository on our server. This repository can be used to install more recent versions of software than the ones included in the stable repositories.<\/p>\n<p>Add the backports repository to your server by typing:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">echo &#8217;deb http:\/\/ftp.debian.org\/debian jessie-backports main&#8217; | sudo tee \/etc\/apt\/sources.list.d\/backports.list<\/li>\n<\/ul>\n<p>After adding the new repository, update the <code>apt<\/code> package index to download information about the new packages:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo apt-get update<\/li>\n<\/ul>\n<p>Once the repository is updated, you can install the <code>python-certbot-apache<\/code> package, which pulls in <code>certbot<\/code>, by targeting the backports repository:<\/p>\n<p><strong>Note:<\/strong> When using backports, it is recommended to only install the specific packages you require, rather than using the repository for general updates. Backport packages have fewer compatibility guarantees than the main repositories.<\/p>\n<p>To help avoid accidentally installing or updating packages using this repository, you must explicitly pass the <code>-t<\/code> flag with the repository name to install packages from backports.<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo apt-get install python-certbot-apache -t jessie-backports<\/li>\n<\/ul>\n<p>The <code>certbot<\/code> client should now be ready to use.<\/p>\n<h2 id=\"step-2-set-up-the-apache-servername-and-serveralias\">Step 2: Set Up the Apache ServerName and ServerAlias<\/h2>\n<p>It is possible to pass the domains that we wish to secure as arguments when calling the <code>certbot<\/code> utility. However, <code>certbot<\/code> can also read these from the Apache configuration itself. Since it is good practice to always be explicit about the domains your server should respond to, we will set the <code>ServerName<\/code> and <code>ServerAlias<\/code> in the Apache configuration directly.<\/p>\n<p>When we installed the <code>python-certbot-apache<\/code> service, Apache was installed if it wasn&#8217;t already present on the system. Open the default Apache Virtual Host file so that we can explicitly set our domain names:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo nano \/etc\/apache2\/sites-available\/000-default.conf<\/li>\n<\/ul>\n<p>Inside, within the Virtual Host block, add or uncomment the <code>ServerName<\/code> directive and set it to your primary domain name. Any alternative domain names that this server should also respond to can be added using a <code>ServerAlias<\/code> directive.<\/p>\n<p>For our example, we are using <code>example.com<\/code> as our canonical name and <code>www.example.com<\/code> as an alias. When we set these directives, it will look like this:<\/p>\n<div class=\"code-label \" title=\"\/etc\/apache2\/sites-available\/000-default.conf\">\/etc\/apache2\/sites-available\/000-default.conf<\/div>\n<pre class=\"code-pre \"><code>&lt;VirtualHost *:80&gt;\r\n    . . .\r\n    ServerName <span class=\"highlight\">example.com<\/span>\r\n    ServerAlias <span class=\"highlight\">www.example.com<\/span>\r\n    . . .\r\n&lt;\/VirtualHost&gt;\r\n<\/code><\/pre>\n<p>When you are finished, save and close the file by holding <strong>CTRL<\/strong> and pressing <strong>X<\/strong>. Type <strong>Y<\/strong> and hit <strong>Enter<\/strong> to save the file.<\/p>\n<p>Check the configuration file to catch any syntax errors that may have been introduced by your changes:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo apache2ctl configtest<\/li>\n<\/ul>\n<p>Look for this line in the output:<\/p>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>Syntax OK\r\n<\/code><\/pre>\n<p>If the file passed the syntax test, restart your Apache service to implement your changes:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo systemctl restart apache2<\/li>\n<\/ul>\n<p>Now that Apache is configured with your domain names, we can use <code>certbot<\/code> to obtain our SSL certificates.<\/p>\n<h2 id=\"step-3-adjusting-the-firewall\">Step 3: Adjusting the Firewall<\/h2>\n<p>If you have a firewall enabled, you&#8217;ll need to adjust the settings to allow for SSL traffic. The required procedure depends on the firewall software you are using. If you do not have a firewall configured currently, feel free to skip forward.<\/p>\n<h3 id=\"ufw\">UFW<\/h3>\n<p>If you are using <strong>ufw<\/strong>, you can see the current setting by typing:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo ufw status<\/li>\n<\/ul>\n<p>It may look like this, meaning that only SSH traffic is allowed to the web server:<\/p>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>Status: active\r\n\r\nTo                         Action      From\r\n--                         ------      ----\r\nSSH                        ALLOW       Anywhere\r\nSSH (v6)                   ALLOW       Anywhere (v6)\r\n<\/code><\/pre>\n<p>To additionally let in HTTP and HTTPS traffic, we can allow the &#8220;WWW Full&#8221; application profile:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo ufw allow &#8216;WWW Full&#8217;<\/li>\n<\/ul>\n<p>Your status should look like this now:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo ufw status<\/li>\n<\/ul>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>Status: active\r\n\r\nTo                         Action      From\r\n--                         ------      ----\r\nSSH                        ALLOW       Anywhere\r\nWWW Full                   ALLOW       Anywhere\r\nSSH (v6)                   ALLOW       Anywhere (v6)\r\nWWW Full (v6)              ALLOW       Anywhere (v6)\r\n<\/code><\/pre>\n<p>HTTP and HTTPS requests should now be accepted by your server.<\/p>\n<h3 id=\"iptables\">IPTables<\/h3>\n<p>If you are using <code>iptables<\/code>, you can see the current rules by typing:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo iptables -S<\/li>\n<\/ul>\n<p>If you have any rules enabled, they will be displayed. An example configuration might look like this:<\/p>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>-P INPUT DROP\r\n-P FORWARD ACCEPT\r\n-P OUTPUT ACCEPT\r\n-A INPUT -i lo -j ACCEPT\r\n-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT\r\n-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT\r\n-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT\r\n<\/code><\/pre>\n<p>The commands needed to open SSL traffic will depend on your current rules. For a basic rule set like the one above, you can add SSL access by typing:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo iptables -I INPUT -p tcp &#8211;dport 443 -j ACCEPT<\/li>\n<\/ul>\n<p>If we look at the firewall rules again, we should see the new rule:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo iptables -S<\/li>\n<\/ul>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>-P INPUT DROP\r\n-P FORWARD ACCEPT\r\n-P OUTPUT ACCEPT\r\n<span class=\"highlight\">-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT<\/span>\r\n-A INPUT -i lo -j ACCEPT\r\n-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT\r\n-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT\r\n-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT\r\n<\/code><\/pre>\n<p>If you are using a program to automatically apply <code>iptables<\/code> rules at boot, you will want to make sure that you update your configuration with the new rule.<\/p>\n<h2 id=\"step-4-set-up-the-ssl-certificate\">Step 4: Set Up the SSL Certificate<\/h2>\n<p>Generating the SSL Certificate for Apache using the Let&#8217;s Encrypt client is quite straightforward. The client will automatically obtain and install a new SSL certificate that is valid for the domains in our Apache configuration.<\/p>\n<p>To execute the interactive installation and obtain a certificate for all of the domains defined in your Apache configuration, type:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo certbot &#8211;apache (apache ees on kaks &#8211; m\u00e4rki)<\/li>\n<\/ul>\n<p>The <code>certbot<\/code> utility will evaluate your Apache configuration to find the domains that should be covered with the requested certificate. You will be able to deselect any defined domains that you do not wish to be covered under the certificate.<\/p>\n<p>You will be presented with a step-by-step guide to customize your certificate options. You will be asked to provide an email address for lost key recovery and notices, and you will be able to choose between enabling both <code>http<\/code> and <code>https<\/code> access or forcing all requests to redirect to <code>https<\/code>. It is usually safest to require <code>https<\/code>, unless you have a specific need for unencrypted <code>http<\/code> traffic.<\/p>\n<p>When the installation is finished, you should be able to find the generated certificate files at <code>\/etc\/letsencrypt\/live<\/code>. You can verify the status of your SSL certificate with the following link (don&#8217;t forget to replace <span class=\"highlight\">example.com<\/span> with your domain):<\/p>\n<pre class=\"code-pre \"><code>https:\/\/www.ssllabs.com\/ssltest\/analyze.html?d=<span class=\"highlight\">example.com<\/span>&amp;latest\r\n<\/code><\/pre>\n<p>The test may take a few minutes to complete. You should now be able to access your website using a <code>https<\/code> prefix.<\/p>\n<h2 id=\"step-5-set-up-auto-renewal\">Step 5: Set Up Auto Renewal<\/h2>\n<p>Let&#8217;s Encrypt certificates are valid for 90 days, but it&#8217;s recommended that you renew the certificates every 60 days to allow a margin of error. The <code>certbot<\/code> client has a <code>renew<\/code> command that automatically checks the currently installed certificates and tries to renew them if they are less than 30 days away from the expiration date.<\/p>\n<p>To trigger the renewal process for all installed domains, you should run:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo certbot renew<\/li>\n<\/ul>\n<p>Because we recently installed the certificate, the command will only check for the expiration date and print a message informing that the certificate is not due to renewal yet. The output should look similar to this:<\/p>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>Saving debug log to \/var\/log\/letsencrypt\/letsencrypt.log\r\n\r\n-------------------------------------------------------------------------------\r\nProcessing \/etc\/letsencrypt\/renewal\/<span class=\"highlight\">example.com<\/span>.conf\r\n-------------------------------------------------------------------------------\r\nCert not yet due for renewal\r\n\r\nThe following certs are not due for renewal yet:\r\n  \/etc\/letsencrypt\/live\/<span class=\"highlight\">example.com<\/span>\/fullchain.pem (skipped)\r\nNo renewals were attempted.\r\n<\/code><\/pre>\n<p>Notice that if you created a bundled certificate with multiple domains, only the base domain name will be shown in the output, but the renewal should be valid for all domains included in this certificate.<\/p>\n<p>A practical way to ensure your certificates won&#8217;t get outdated is to create a cron job that will periodically execute the automatic renewal command for you. Since the renewal first checks for the expiration date and only executes the renewal if the certificate is less than 30 days away from expiration, it is safe to create a cron job that runs every week or even every day, for instance.<\/p>\n<p>Let&#8217;s edit the crontab to create a new job that will run the renewal command every week. To edit the crontab for the root user, run:<\/p>\n<ul class=\"prefixed\">\n<li class=\"line\">sudo crontab -e<\/li>\n<\/ul>\n<p>You may be prompted to select an editor:<\/p>\n<div class=\"secondary-code-label \" title=\"Output\">Output<\/div>\n<pre class=\"code-pre \"><code>no crontab for root - using an empty one\r\n\r\nSelect an editor.  To change later, run 'select-editor'.\r\n  1. \/bin\/nano        &lt;---- easiest\r\n  2. \/usr\/bin\/vim.basic\r\n  3. \/usr\/bin\/vim.tiny\r\n\r\nChoose 1-3 [1]:\r\n<\/code><\/pre>\n<p>Unless you&#8217;re more comfortable with <code>vim<\/code>, press <strong>Enter<\/strong> to use <code>nano<\/code>, the default.<\/p>\n<p>Include the following content at the end of the crontab, all in one line:<\/p>\n<div class=\"secondary-code-label \" title=\"crontab\">crontab<\/div>\n<pre class=\"code-pre \"><code>. . .\r\n30 2 * * 1 \/usr\/bin\/certbot renew &gt;&gt; \/var\/log\/le-renew.log\r\n<\/code><\/pre>\n<p>Save and exit. This will create a new cron job that will execute the <code>letsencrypt-auto renew<\/code> command every Monday at 2:30 am. The output produced by the command will be piped to a log file located at <code>\/var\/log\/le-renewal.log<\/code>.<\/p>\n<p><span class=\"note\">For more information on how to create and schedule cron jobs, you can check our <a href=\"https:\/\/www.digitalocean.com\/community\/tutorials\/how-to-use-cron-to-automate-tasks-on-a-vps\">How to Use Cron to Automate Tasks in a VPS<\/a> guide. <\/span><\/p>\n<h2 id=\"conclusion\">Conclusion<\/h2>\n<p>In this guide, we saw how to install a free SSL certificate from Let&#8217;s Encrypt in order to secure a website hosted with Apache. We recommend that you check the official <a href=\"https:\/\/letsencrypt.org\/blog\/\">Let&#8217;s Encrypt blog<\/a> for important updates from time to time.<\/p>\n<p>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<\/p>\n<\/div>\n<p>000-default-le-ssl.conf faili seaded on all pool<\/p>\n<hr \/>\n<pre><code class=\"hljs apache\"><span class=\"hljs-section\">&lt;IfModule mod_ssl.c&gt;<\/span>\r\n<span class=\"hljs-section\">&lt;VirtualHost *:443&gt;<\/span>\r\n\t<span class=\"hljs-comment\"># The ServerName directive sets the request scheme, hostname and port that<\/span>\r\n\t<span class=\"hljs-comment\"># the server uses to identify itself. This is used when creating<\/span>\r\n\t<span class=\"hljs-comment\"># redirection URLs. In the context of virtual hosts, the ServerName<\/span>\r\n\t<span class=\"hljs-comment\"># specifies what hostname must appear in the request's Host: header to<\/span>\r\n\t<span class=\"hljs-comment\"># match this virtual host. For the default virtual host (this file) this<\/span>\r\n\t<span class=\"hljs-comment\"># value is not decisive as it is used as a last resort host regardless.<\/span>\r\n\t<span class=\"hljs-comment\"># However, you must set it for any further virtual host explicitly.<\/span>\r\n\t<span class=\"hljs-comment\">#ServerName www.example.com<\/span>\r\n    <span class=\"hljs-attribute\">ServerAdmin<\/span> webmaster@localhost\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">DocumentRoot<\/span><\/span> \/var\/www\/html\r\n\r\n<span class=\"hljs-comment\"># Available loglevels: trace8, ..., trace1, debug, info, notice, warn,<\/span>\r\n<span class=\"hljs-comment\"># error, crit, alert, emerg.<\/span>\r\n<span class=\"hljs-comment\"># It is also possible to configure the loglevel for particular<\/span>\r\n<span class=\"hljs-comment\"># modules, e.g.<\/span>\r\n<span class=\"hljs-comment\">#LogLevel info ssl:warn<\/span>\r\n\r\n<span class=\"hljs-attribute\">ErrorLog<\/span> <span class=\"hljs-variable\">${APACHE_LOG_DIR}<\/span>\/error.log\r\n<span class=\"hljs-attribute\">CustomLog<\/span> <span class=\"hljs-variable\">${APACHE_LOG_DIR}<\/span>\/access.log combined\r\n\r\n<span class=\"hljs-comment\"># For most configuration files from conf-available\/, which are<\/span>\r\n<span class=\"hljs-comment\"># enabled or disabled at a global level, it is possible to<\/span>\r\n<span class=\"hljs-comment\"># include a line for only one particular virtual host. For example the<\/span>\r\n<span class=\"hljs-comment\"># following line enables the CGI configuration for this host only<\/span>\r\n<span class=\"hljs-comment\"># after it has been globally disabled with \"a2disconf\".<\/span>\r\n<span class=\"hljs-comment\">#Include conf-available\/serve-cgi-bin.conf<\/span>\r\n<span class=\"hljs-attribute\">SSLCertificateFile<\/span> \/etc\/letsencrypt\/live\/mydomain.it\/cert.pem\r\n<span class=\"hljs-attribute\">SSLCertificateKeyFile<\/span> \/etc\/letsencrypt\/live\/mydomain.it\/privkey.pem\r\n<span class=\"hljs-attribute\">Include<\/span> \/etc\/letsencrypt\/options-ssl-apache.conf\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">ServerName<\/span><\/span> mydomain.it\r\n<span class=\"hljs-attribute\">ServerAlias<\/span> www.mydomain.it\r\n<span class=\"hljs-attribute\">SSLCertificateChainFile<\/span> \/etc\/letsencrypt\/live\/mydomain.it\/chain.pem\r\n    \r\n<span class=\"hljs-section\">&lt;Directory \"\/var\/www\/html\/test\"&gt;<\/span>\r\n\t<span class=\"hljs-attribute\">AuthType<\/span> Basic\r\n\t<span class=\"hljs-attribute\">AuthName<\/span> <span class=\"hljs-string\">\"Restricted Content\"<\/span>\r\n\t<span class=\"hljs-attribute\">AuthUserFile<\/span> \/etc\/apache2\/.htpasswd\r\n\t<span class=\"hljs-attribute\">Require<\/span> valid-user\r\n<span class=\"hljs-section\">&lt;\/Directory&gt;<\/span>\r\n<span class=\"hljs-section\">&lt;\/VirtualHost&gt;<\/span>\r\n<span class=\"hljs-comment\"># vim: syntax=apache ts=4 sw=4 sts=4 sr noet<\/span>\r\n<span class=\"hljs-section\">&lt;\/IfModule&gt;\r\n----------------------<\/span><\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>000-default.conf faili seaded on all pool<\/p>\n<hr \/>\n<pre><code class=\"hljs apache\"><span class=\"hljs-section\">&lt;VirtualHost *:80&gt;<\/span>\r\n\t<span class=\"hljs-comment\"># The ServerName directive sets the request scheme, hostname and port that<\/span>\r\n\t<span class=\"hljs-comment\"># the server uses to identify itself. This is used when creating<\/span>\r\n\t<span class=\"hljs-comment\"># redirection URLs. In the context of virtual hosts, the ServerName<\/span>\r\n\t<span class=\"hljs-comment\"># specifies what hostname must appear in the request's Host: header to<\/span>\r\n\t<span class=\"hljs-comment\"># match this virtual host. For the default virtual host (this file) this<\/span>\r\n\t<span class=\"hljs-comment\"># value is not decisive as it is used as a last resort host regardless.<\/span>\r\n\t<span class=\"hljs-comment\"># However, you must set it for any further virtual host explicitly.<\/span>\r\n\t<span class=\"hljs-comment\">#ServerName www.example.com<\/span>\r\n    <span class=\"hljs-attribute\">ServerAdmin<\/span> webmaster@localhost\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">DocumentRoot<\/span><\/span> \/var\/www\/html\r\n\r\n<span class=\"hljs-comment\"># Available loglevels: trace8, ..., trace1, debug, info, notice, warn,<\/span>\r\n<span class=\"hljs-comment\"># error, crit, alert, emerg.<\/span>\r\n<span class=\"hljs-comment\"># It is also possible to configure the loglevel for particular<\/span>\r\n<span class=\"hljs-comment\"># modules, e.g.<\/span>\r\n<span class=\"hljs-comment\">#LogLevel info ssl:warn<\/span>\r\n\r\n<span class=\"hljs-attribute\">ErrorLog<\/span> <span class=\"hljs-variable\">${APACHE_LOG_DIR}<\/span>\/error.log\r\n<span class=\"hljs-attribute\">CustomLog<\/span> <span class=\"hljs-variable\">${APACHE_LOG_DIR}<\/span>\/access.log combined\r\n\r\n<span class=\"hljs-comment\"># For most configuration files from conf-available\/, which are<\/span>\r\n<span class=\"hljs-comment\"># enabled or disabled at a global level, it is possible to<\/span>\r\n<span class=\"hljs-comment\"># include a line for only one particular virtual host. For example the<\/span>\r\n<span class=\"hljs-comment\"># following line enables the CGI configuration for this host only<\/span>\r\n<span class=\"hljs-comment\"># after it has been globally disabled with \"a2disconf\".<\/span>\r\n<span class=\"hljs-comment\">#Include conf-available\/serve-cgi-bin.conf<\/span>\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">RewriteEngine<\/span><\/span> <span class=\"hljs-literal\">on<\/span>\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">RewriteCond<\/span><\/span> <span class=\"hljs-variable\">%{SERVER_NAME}<\/span> =www.mydomain.it<span class=\"hljs-meta\"> [OR]<\/span>\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">RewriteCond<\/span><\/span> <span class=\"hljs-variable\">%{SERVER_NAME}<\/span> =mydomain.it\r\n<span class=\"hljs-attribute\"><span class=\"hljs-nomarkup\">RewriteRule<\/span><\/span> ^ https:\/\/<span class=\"hljs-variable\">%{SERVER_NAME}<\/span><span class=\"hljs-variable\">%{REQUEST_URI}<\/span><span class=\"hljs-meta\"> [END,QSA,R=permanent]<\/span>\r\n\t<span class=\"hljs-section\">&lt;Directory \"\/var\/www\/html\/test&gt;<\/span>\r\n\t\t<span class=\"hljs-attribute\">AuthType<\/span> Basic\r\n\t\t<span class=\"hljs-attribute\">AuthName<\/span> <span class=\"hljs-string\">\"Restricted Content\"<\/span>\r\n\t\t<span class=\"hljs-attribute\">AuthUserFile<\/span> \/etc\/apache2\/.htpasswd\r\n\t\t<span class=\"hljs-attribute\">Require<\/span> valid-user\r\n\t<span class=\"hljs-section\">&lt;\/Directory&gt;<\/span>\r\n<span class=\"hljs-section\">&lt;\/VirtualHost&gt;<\/span>\r\n<span class=\"hljs-comment\"># vim: syntax=apache ts=4 sw=4 sts=4 sr noet\r\n-------------------------------<\/span><\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"<p>How To Secure Apache with Let&#8217;s Encrypt on Debian 8 Introduction This tutorial will show you how to set up a TLS\/SSL certificate from Let&#8217;s Encrypt on a Debian 8 server running Apache as a web server. We will also cover how to automate the certificate renewal process using a cron job. SSL certificates are [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":621,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"class_list":["post-680","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/pages\/680","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=680"}],"version-history":[{"count":4,"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/pages\/680\/revisions"}],"predecessor-version":[{"id":689,"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/pages\/680\/revisions\/689"}],"up":[{"embeddable":true,"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=\/wp\/v2\/pages\/621"}],"wp:attachment":[{"href":"https:\/\/helia.ee\/koolitus\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=680"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}