Duckdns, apache2.4 and invalid security certificate


#1

HI, I am new to LetsEncryt and I am struggling to get SSL working with apache2.4 on raspbian stretch with duckdns. To try and keep things striaghtforward I am currently running everything on their defaults. I originally had a server running just fine with duckdns and apache without SSL enabled. I then installed certbot and was getting the error SEC_ERROR_UNKNOWN_ISSUER. I figured the problem was probably with my configuration, so I decided to do a completely fresh reinstall of everything and start over leaving everything on their default settings, get the site running on default and install certbot again using the defaults but I still get the same error saying my certificate is invalid.

When setting up certbot I used
sudo certbot --apache -d www.web-net.duckdns.org
and then I selected option 2 to redirect to HTTPS.

I’ve checked my port forwarding and both ports 80 and 443 are open. When I go to test my site on ssllabs I get the error Assessment failed: Unable to connect to the server.

Ive looked through and attached my sites-available configurations below but they all look to be correct. I have also ran sudo certbot --apache and tried attempt to reinstall this existing certificate

when I run
sudo openssl x509 -noout -text -in /etc/letsencrypt/live/www.web-net.duckdns.org/cert.pem
it shows my certificate and I think this might be the important part of the certificate to show

Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Apr  5 18:13:21 2018 GMT
            Not After : Jul  4 18:13:21 2018 GMT
        Subject: CN = www.web-net.duckdns.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption

Can anyone help me with getting everything set up correctly and have I missed any steps in the setup process?

Edit: I should probably also add that I have spent the last 4-5 days looking through SEC_ERROR_UNKNOWN_ISSUER topics on this forum and other forums to try and resolve the issue but none of the fixes suggested have worked or I havn’t fully understood them due to being specific to a persons setup and could only partially attempt the solution.

Configuration FIles:

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

        ServerName www.web-net.duckdns.org
        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
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.web-net.duckdns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

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

000-default-le-ssl.conf

<VirtualHost *:4343>
# 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


ServerName www.web-net.duckdns.org
Include /etc/letsencrypt/options-ssl-apache.conf
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/www.web-net.duckdns.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.web-net.duckdns.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

default-ssl.conf


ServerName www.web-net.duckdns.org
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

                #   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
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                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

#2

Hi @Chriss316,

You should change port 4343 to 443 in 000-default-le-ssl.conf and restart apache.

Cheers,
sahsanu


#3

Ah I forgot to change that when copy pasting, just before posting I tried setting all ports to 4343 as well as on my external and internal ports on the router to see if it was maybe a port issue, but I have while posting put 000-default.conf back to 80 and the other 2 back to 443 (same on router), and I have also changed the ports.conf to reflect the same changes and restarted apache.


#4

@Chriss316, I can’t connect to your site neither using port 80 nor 443 but I can connect to port 4343 and as before I posted my first message, it is serving the right Let’s Encrypt certificate.

https://www.web-net.duckdns.org:4343


#5

Hmm, I checked the router and it was set to 80 and 443, I deleted the port forward rule and recreated it and also restarted apache again so everything should now be back on 80 and 443

Still showing me the SEC_ERROR_UNKNOWN_ISSUER on my end, how do I tell if it is serving the right certificate?


#6

I don’t know what you did, maybe redirect port 80 on your router to port 443 in your raspberry but right now you are serving the TLS connection on port 80… and again, it is serving the right certificate.

$ echo | openssl s_client -connect www.web-net.duckdns.org:80 -servername www.web-net.duckdns.org 2>/dev/null | openssl x509 -noout -text | grep -E '(Before:|Issuer:|DNS:)' | sed "s/^[ \t]*//"
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Not Before: Apr  5 18:13:21 2018 GMT
DNS:www.web-net.duckdns.org

Now this site is showing the text: Apache Test Page and when it was listening on port 4343 it was showing a picture gallery so you are changing a few things at the same time :stuck_out_tongue:

Re-check the port forwarding in your router and the Apache conf… also, disable the default-ssl.conf.

a2dissite default-ssl

and restart Apache.

Cheers,
sahsanu


#7

Haha yea the gallery was the main page I am working on at the minute, was testing on my phone and got a blank screen and couldnt tell if it was an issue with the server or with the website so to simplify and speed up loading I replaced the www folder with a basic html file but then I got a “Bad Request” page so it seems firefox on my phone cant auto redirect HTTP to HTTPS, when I added in the S it then takes me to the invalid certificate page

I ran a2dissite default-ssl and got the message Site default-ssl already disabled

I ran echo | openssl s_client -connect www.web-net.duckdns.org:80 -servername www.web-net.duckdns.org 2>/dev/null | openssl x509 -noout -text | grep -E '(Before:|Issuer:|DNS:)' | sed "s/^[ \t]*//"

and get
unable to load certificate
1995777440:error:0906D06C:PEM routines:PEM_read_bio:no start line:…/crypto/pem/pem_lib.c:691:Expecting: TRUSTED CERTIFICATE


#8

That is because you are testing it from your internal network and you are no affected by the port-forwarding in your router, change the port 80 by 443 and check again.

echo | openssl s_client -connect www.web-net.duckdns.org:443 -servername www.web-net.duckdns.org 2>/dev/null | openssl x509 -noout -text | grep -E '(Before:|Issuer:|DNS:)' | sed "s/^[ \t]*//"

And again, check the rules on your router because as I said, seems it is redirecting port 80 to port 443 and port 443 to…???


#9

Right of course, I keep forgetting I cant test externally on my network, the amount of times I’ve done that tonight :grin:

Ok I think I have maybe got it somewhat working, I removed port 80 from the equation on my router, while keeping 000-default.conf set to 80 and 000-default-le-ssl.conf set to 443, on my phone if I just type in web-net.duckdns.org, it tries to connect to HTTP by default and then it finishes loading and just displays a completely blank page with nothing on it, if I then go into the url and change the HTTP to HTTPS it then loads the test page, its the same on Firefox and Chrome, not sure thats because the router is no longer redirecting port 80 or if the phone browsers cant redirect to HTTPS?

On Safari it still gave me an untrusted message, I then went into the details and it gave a ton of information on the certificate details, I then closed it and tried again and it loads the HTTPS just fine, however I’m not entirely certain if I accidently trusted it myself, need to see if it saved the certificate as a trusted or not


#10

@Chriss316, ok, now port 80 is not working but 443 is working and servig the right certificate.

Wait a minute, your certificate covers www.web-net.duckdns.org but it doesn’t cover web-net.duckdns.org so trying to access to your domain without www will give you the error SSL_ERROR_BAD_CERT_DOMAIN, also, I can’t see any ServerName nor ServerAlias directive in your apache conf…

As a resume:

1.- Your port forward from port 80 on your router to port 80 on raspberry doesn’t work.
2.- Your port forward from port 443 on your router to port 443 on raspberry works and it is serving the right cert but it is only valid for your www domain.
3.- Your browser issues seems related to a cache problem, also, keep in mind that browsers like Chrome, if can’t reach a domain, it tries the www version and/or the https version so you can try to reach http://web-net.duckdns.org but as the browser can’t connect it tries https://web-net.duckdns.org and/or http://www.web-net.duckdns.org and/or https://www.web-net.duckdns.org

So, you only need to polish the router conf and decide if you want the cert covering both domains (7 days ago you issued a cert covering both domains).

CRT ID     DOMAIN (CN)              VALID FROM             VALID TO               EXPIRES IN  SANs
370910578  www.web-net.duckdns.org  2018-Mar-30 18:32 UTC  2018-Jun-28 18:32 UTC  83 days     web-net.duckdns.org
                                                                                              www.web-net.duckdns.org

Time to sleep here :wink:

Good luck,
sahsanu


#11

Oh right I forgot about that, the one from a week ago, I registered without the www and then started trying to learn more about how to work with certificates and I thought I had set it up wrong by not adding the www so I added the second with the www, thats when I thought I wasnt doing things right and decided to start again from scratch.

And your right it was me that was flipping back and forth between https:// and http://www without noticing which is what was giving me mixed results, definatly need to take a break and come back to it in the morning and add the domain without the www too

Checked it on ssllabs and its working perfectly fine there now too, thanks for all the help :smile:


#12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.