wscotgrey
By:
wscotgrey

ubuntu 16.04 self-signed cert versus let's encrypt error

April 21, 2017 815 views
Apache Ubuntu 16.04

Hey There,

I have looked all over the interwebs for the answer to this, and can't find one, so if this is redundant, I am sorry:

I installed ubuntu 16.04 on my Droplet, and put in the LAMP stack. I manage a wordpress site, so I added that. Wordpress only works with https, so I needed a certificate for the site.

I first used the tutorial here, and it worked, I guess, except that there were huge warnings all over Chrome and Safari that the site wasn't safe!!, so I realized I needed an external CA, so I used this tutorial here. Man was that easy, except...

At this point I was getting the errconnectionrefused and failure on load for the browsers, and I determined that it was an error relating to the two certificates. So I followed this, and part of that answer was to go back through the self-signed tutorial backwards. I disabled OpenSSH in the firewall, and enabled it, and tried several things, so now I think I've screwed myself and it is so all over the place that I will have to start over at the stack install to correct it.

So my question is this:

Is there a way to remove all traces of SSH protocols to start over at bare encryption again, or do I have to do a clean install, again.

I am out of ideas on how to fix this, and admittedly am not a network admin, so I am sure I simply messed something up, including not providing enough info here for proper answers from the forum, but I could really use some answers, otherwise it is back to square one tomorrow.

Thanks for allowing me this desperate moment.

Scot

4 Answers
hansen April 21, 2017
Accepted Answer

Hi @wscotgrey

You went the long way, I would say, but let's see if we can get you back :-)

I don't see why Apache certificates should have anything to do with SSH, but I'm guessing that's just a typo and you meant SSL.

It would probably be easier if you paste the Apache vhost configuration for your site.
Once we've cleaned up the configuration, then it should be fairly easy to follow the Let's Encrypt tutorial, which you already followed with ease.

Your vhost configuration file(s) is located in /etc/apache2/sites-enabled/

  • In the sites-enabled directory are three files; 000-default.conf, 000-default-le-ssl.conf, and default-ssl.conf.

    Which would you think is the more likely culprit?

    I would post them all, but I did and was reported as spam, so I am trying this way,
    Also, thanks for the rapid response. I appreciate it greatly.

    Scot

    • @wscotgrey
      It could be anyone of these, but since you have two ssl named files, I would recommend removing default-ssl.conf.
      I think it's just a link, so run unlink default-ssl.conf to remove it.
      And service apache2 reload

    • @wscotgrey

      000-default-le-ssl.conf is your LetsEncrypt configuration, so that one should be kept if you want to keep the valid SSL Certificate in place.

      LetsEncrypt tags the configuration files with the -le-, so you can easily identify which of the configuration files come from the generator by looking for that tag.

      The other, default-ssl.conf should be removed as if it's being included along with the one tagged -le-, then that's where the errors are most likely stemming from.

      You'll need to restart Apache after removing the configuration file, or start it if Apache failed and isn't running.

      • Brilliant! Thanks jtittle!

        That moved me forward. I have another question for you though:

        So now the browser is giving me the too many redirects error.

        I've checked the droplets networking menu and I have records as follows:

        type, hostname,directs to,...
        NS,mysite.com,mysite.com
        A,mysite.com,ipaddress
        CNAME, .*mysite.com,is an alias of mysite.com
        A,mysite.com,ipaddress

        As far as my LAMP stack setup, I am not sure, but I'm sure I've messed that up too.

        I have also haven't found much info on this problem too. Usually the articles are related to the CNAME, and Wordpress, so I've followed a few of those, but I still haven't gotten there.

        Again, thanks for the simple fix on the SSL error. I had no idea it would be that simple.

        Also, sorry for dropping out on the issue last night. A day of pounding at this had worn me out.

        And, last question, should I start a new thread with this new question, or is it appropriate here? I see on StackOverflow people get remonstrated for bad etiquette, so I am trying to keep myself in check.

        Thanks again,
        Scot

        • @wscotgrey

          When it comes to DNS, I'll use domain.com as the domain and DO_IP as the IP of your Droplet in the following.

          Your DNS A and CNAME entries should look something like this:

          A          domain.com          DO_IP
          A          *                   DO_IP
          CNAME      www                 domain.com
          

          The above:

          1). Points your domain to your Droplet IP.
          2). Adds a WildCard DNS Entry pointing to your Droplet IP.
          3). Allows the use of www.domain.com.

          You shouldn't have a CNAME with * setup. WildCard DNS should be setup using an A entry (as above).

          Once the WildCard is setup, anything.domain.com will point to domain.com unless you have a valid VirtualHost block setup for the sub-domain.

          i.e.

          sub.domain.com          =>          domain.com
          sub2.domain.com         =>          domain.com
          my.domain.com           =>          domain.com
          dfaghdfj.domain.com     =>          domain.com
          

          As far as the NS entries, those should either point to DigitalOcean's DNS, or that of your provider unless you're trying to setup vanity DNS using your domain, in which case you'd need to setup a DNS server (which is beyond the scope of the tutorials provided for a LAMP stack configuration).

          That said, you don't need a DNS server -- DigitalOcean or your domain registrar can handle DNS for you. You'd just make the changes through their control panel.

          ...

          As far as the error stating that there's too many redirects, that could be due to a few issues.

          1). A .htaccess file in the web root (where your index file exists).

          2). You're using CloudFlare.

          If you have an .htaccess file, back it up (download it) and delete it for now.

          If you're using CloudFlare, you need to login to their control panel, navigate to the Crypto menu and in the first box labeled SSL, choose Full (Strict) from the drop down menu.

          • Hey J,

            Man I feel like such a noob next to you.

            I fixed my droplet settings to your instructions, and that didn't fix the error.

            I don't have CloudFlare, so I copied and deleted the .htaccess file in my /var/www/html directory. Unfortunately that didn't fix it

            So, I put it back, and just to make sure you see it, here's the code:

            # BEGIN WordPress
            <IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteBase /
            RewriteRule ^index\.php$ - [L]
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteCond %{REQUEST_FILENAME} !-d
            RewriteRule . /index.php [L]
            </IfModule>
            # END WordPress
            

            Of course, I also restarted the server.

            Any other suggestions?
            Thanks again, and in advance,

            Scot

@wscotgrey

New reply as the previous was maxed :-).

Have you changed your WordPress URL to use https instead of http? If not, we need to do that now.

If not, open up your wp-config.php file and find define('WP_DEBUG', false);, then directly below it, add the following (change domain.com to your domain).

define('WP_HOME','http://domain.com');
define('WP_SITEURL','http://domain.com');

Save the file and try accessing your site again, or upload the file back (if you didn't modify it from the CLI).

Also, if that one file, default-ssl.conf, still exists, delete it and restart Apache.

  • Sorry this is taking so long.
    `default-ssl.confis deleted. That fixed the problem of denied access error.

    I edited wp-config.php in /var/www/html to follow your instructions, ( define ('WP_DEBUG', false'); was already there, but I added the other two lines to no avail.

    I had already followed the instruction to make WP use https, but have lost where and when I edited and probably fouled that up too.

    I'm going to inundate you with thanks for your efforts, both post and pre.

    Next?
    Scot

    • @wscotgrey

      In 000-default-le-ssl.conf, comment out this line:

      Redirect permanent  "/" "https://mysite.com/"
      

      So that it looks like:

      #Redirect permanent  "/" "https://mysite.com/"
      

      I don't have a demo Droplet setup for Apache + LE right now, though that doesn't make a lot of sense to me. HTTPS shouldn't be redirecting to HTTPS. That line makes sense in your default server block (which references port 80), but not so much in your SSL block.

      Once you comment that out (only in the -le- file), restart Apache.

      • Hansen beat you to it, but that's exactly what I did. It worked, I thank you both for your efforts. I have upvoted them, will upvote you. I wish I could comment on your profile page about the help you two were!

        Thanks again!

        Scot

        • @wscotgrey

          No problem at all :-).

          I was actually in the process of setting up a Droplet to test out the Apache config that LE was using and that line is definitely not there, so glad to see removing it is what resolved the issue.

Sorry about that, I meant SSL, I have 3 files in that directory: 000-default.conf, 000-default-le-ssl.conf, and default-ssl.conf.
I am not sure which you're asking for, so here's, edited for privacy, 000-default.conf:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf

    Redirect permanent  "/" "https://mysite.com/"

Here's 000-default-le-ssl.conf:

<IfModule mod_ssl.c>
<VirtualHost *:443>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf

    Redirect permanent  "/" "https://mysite.com/"

SSLCertificateFile /etc/letsencrypt/live/mysite.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mysite.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ServerName mysite.com
</VirtualHost>

And here's default-ssl.conf:

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin admin@mysite.com
#ServerName mysite.com

            DocumentRoot /var/www/html

            # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
            # error, crit, alert, emerg.
            # It is also possible to configure the loglevel for particular
            # modules, e.g.
            #LogLevel info ssl:warn

            ErrorLog ${APACHE_LOG_DIR}/error.log
            CustomLog ${APACHE_LOG_DIR}/access.log combined

            # For most configuration files from conf-available/, which are
            # enabled or disabled at a global level, it is possible to
            # include a line for only one particular virtual host. For example the
            # following line enables the CGI configuration for this host only
            # after it has been globally disabled with "a2disconf".
            #Include conf-available/serve-cgi-bin.conf

            #   SSL Engine Switch:
            #   Enable/Disable SSL for this virtual host.
            SSLEngine on

            #   A self-signed (snakeoil) certificate can be created by installing
            #   the ssl-cert package. See
            #   /usr/share/doc/apache2/README.Debian.gz for more info.
            #   If both key and certificate are stored in the same file, only the
            #   SSLCertificateFile directive is needed.
            #SSLCertificateFile     /etc/ssl/certs/ssl-cert-snakeoil.pem
            #SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

            #   Server Certificate Chain:
            #   Point SSLCertificateChainFile at a file containing the
            #   concatenation of PEM encoded CA certificates which form the
            #   certificate chain for the server certificate. Alternatively
            #   the referenced file can be the same as SSLCertificateFile
            #   when the CA certificates are directly appended to the server
            #   certificate for convinience.
            #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

            #   Certificate Authority (CA):
            #   Set the CA certificate verification path where to find CA
            #   certificates for client authentication or alternatively one
            #   huge file containing all of them (file must be PEM encoded)
            #   Note: Inside SSLCACertificatePath you need hash symlinks
            #                to point to the certificate files. Use the provided
            #                Makefile to update the hash symlinks after changes.
            #SSLCACertificatePath /etc/ssl/certs/
            #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

            #   Certificate Revocation Lists (CRL):
            #   Set the CA revocation path where to find CA CRLs for client
            #   authentication or alternatively one huge file containing all
            #   of them (file must be PEM encoded)
            #   Note: Inside SSLCARevocationPath you need hash symlinks
            #                to point to the certificate files. Use the provided
            #                Makefile to update the hash symlinks after changes.
            #SSLCARevocationPath /etc/apache2/ssl.crl/
            #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

            #   Client Authentication (Type):
            #   Client certificate verification type and depth.  Types are
            #   none, optional, require and optional_no_ca.  Depth is a
            #   number which specifies how deeply to verify the certificate
            #   issuer chain before deciding the certificate is not valid.
            #SSLVerifyClient require
            #SSLVerifyDepth  10

            #   SSL Engine Options:
            #   Set various options for the SSL engine.
            #   o FakeBasicAuth:
            #        Translate the client X.509 into a Basic Authorisation.  This means that
            #        the standard Auth/DBMAuth methods can be used for access control.  The
            #        user name is the `one line' version of the client's X.509 certificate.
            #        Note that no password is obtained from the user. Every entry in the user
            #        file needs this password: `xxj31ZMTZzkVA'.
            #   o ExportCertData:
            #        This exports two additional environment variables: SSL_CLIENT_CERT and
            #        SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
            #        server (always existing) and the client (only existing when client
            #        authentication is used). This can be used to import the certificates
            #        into CGI scripts.
            #   o StdEnvVars:
            #        This exports the standard SSL/TLS related `SSL_*' environment variables.
            #        Per default this exportation is switched off for performance reasons,
            #        because the extraction step is an expensive operation and is usually
            #        useless for serving static content. So one usually enables the
            #        exportation for CGI and SSI requests only.
            #   o OptRenegotiate:
            #        This enables optimized SSL connection renegotiation handling when SSL
            #        directives are used in per-directory context.
            #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
            <FilesMatch "\.(cgi|shtml|phtml|php)$">
                            SSLOptions +StdEnvVars
            </Directory>

            #   SSL Protocol Adjustments:
            #   The safe and default but still SSL/TLS standard compliant shutdown
            #   approach is that mod_ssl sends the close notify alert but doesn't wait for
            #   the close notify alert from client. When you need a different shutdown
            #   approach you can use one of the following variables:
            #   o ssl-unclean-shutdown:
            #        This forces an unclean shutdown when the connection is closed, i.e. no
            #        SSL close notify alert is send or allowed to received.  This violates
            #        the SSL/TLS standard but is needed for some brain-dead browsers. Use
            #        this when you receive I/O errors because of the standard approach where
            #        mod_ssl sends the close notify alert.
            #   o ssl-accurate-shutdown:
            #        This forces an accurate shutdown when the connection is closed, i.e. a
            #        SSL close notify alert is send and mod_ssl waits for the close notify
            #        alert of the client. This is 100% SSL/TLS standard compliant, but in
            #        practice often causes hanging connections with brain-dead browsers. Use
            #        this only for browsers where you know that their SSL implementation
            #        works correctly.
            #   Notice: Most problems of broken clients are also related to the HTTP
            #   keep-alive facility, so you usually additionally want to disable
            #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
            #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
            #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
            #   "force-response-1.0" for this.
            # BrowserMatch "MSIE [2-6]" \
            #               nokeepalive ssl-unclean-shutdown \
            #               downgrade-1.0 force-response-1.0

    </VirtualHost>

</IfModule>

vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Thanks also for the rapid response. It is heartening.

Scot

  • @wscotgrey

    You need to remove the line Redirect permanent "/" "https://mysite.com/" from the file 000-default-le-ssl.conf

    That should fix you redirect loop.

    • Hey Hansen,

      That did it!!

      Thanks to both you and Jtittle for your support. I would have wound myself up into knots if it wasn't for you two.
      I will be singing your praises for a while. Lifesavers!!

Have another answer? Share your knowledge.