Cannot connect to https after successful Certbot certificate installation

Have not been able to get this running at all under https. Have gone from an established system to a fresh re-install of the OS and only the relevant software to get a page to serve through https. After over 48 hours at this I am at a loss of what to do to try and make this work anymore. Any help would be greatly appreciated.

My domain is:
I ran this command:
sudo certbot --apache
It produced this output:
Requesting a certificate for and
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/
Key is saved at: /etc/letsencrypt/live/
This certificate expires on 2021-12-07.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for to /etc/apache2/sites-available/nacnud3000-le-ssl.conf
Successfully deployed certificate for to /etc/apache2/sites-available/nacnud3000-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on and
My web server is (include version):
Apache/2.4.41 (Ubuntu)
The operating system my web server runs on is (include version):
Ubuntu Server 20.04 LTS
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.19.0

Results From:
Handshake failed, we haven't received any certificates from the requested server.
DNS Information
Resolves To:
Reverse IP lookup:
OpenSSL Handshake

no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 208 bytes
Verification: OK
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : TLSv1.2
    Cipher    : 0000
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1631092252
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

I am able to reach my server internally over https://LOCAL_IP with expected 'bad domain' error returned from the browser.

Is there a router and/or firewall between the world wide web and your server?

1 Like

There is.
My router has 80 & 443 open and forwarded to the server.
Server firewall is UFW with Apache Full and OpenSSL allowed.
I've been able to verify that 80 & 443 are visible externally, and regular http functions without issue.

Hi @nacnud3000, welcome to the LE community forum :slight_smile:

The problem seems to be in your Apache config.
Please show the outputs of:
sudo cat /etc/apache2/sites-available/nacnud3000-le-ssl.conf
sudo cat /etc/apache2/mods-enabled/ssl.conf

[I suspect this is the first site to be secured on this server]

Are you using some sort of GeoLocaiton blocking or anything similar?

Hi rg305, thank you for the warm welcome.

This is indeed the first site to be secured on this server. I have a domain that is already hosted by a paid service which I intend to bring over to my server once I have this figured out with the domain I bought for testing (

The outputs are as follows:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        DocumentRoot /var/www/nacnud3000
        ErrorLog ${APACHE_LOG_DIR}/nacnud3000_error.log
        CustomLog ${APACHE_LOG_DIR}/nacnud3000_access.log combined

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/


<IfModule mod_ssl.c>

        # Pseudo Random Number Generator (PRNG):
        # Configure one or more sources to seed the PRNG of the SSL library.
        # The seed data should be of good random quality.
        # WARNING! On some platforms /dev/random blocks if not enough entropy
        # is available. This means you then cannot use the /dev/random device
        # because it would lead to very long connection times (as long as
        # it requires to make more entropy available). But usually those
        # platforms additionally provide a /dev/urandom device which doesn't
        # block. So, if available, use this one instead. Read the mod_ssl User
        # Manual for more details.
        SSLRandomSeed startup builtin
        SSLRandomSeed startup file:/dev/urandom 512
        SSLRandomSeed connect builtin
        SSLRandomSeed connect file:/dev/urandom 512

        ##  SSL Global Context
        ##  All SSL configuration in this context applies both to
        ##  the main server and all SSL-enabled virtual hosts.

        #   Some MIME-types for downloading Certificates and CRLs
        AddType application/x-x509-ca-cert .crt
        AddType application/x-pkcs7-crl .crl

        #   Pass Phrase Dialog:
        #   Configure the pass phrase gathering process.
        #   The filtering dialog program (`builtin' is a internal
        #   terminal dialog) has to provide the pass phrase on stdout.
        SSLPassPhraseDialog  exec:/usr/share/apache2/ask-for-passphrase

        #   Inter-Process Session Cache:
        #   Configure the SSL Session Cache: First the mechanism
        #   to use and second the expiring timeout (in seconds).
        #   (The mechanism dbm has known memory leaks and should not be used).
        #SSLSessionCache                 dbm:${APACHE_RUN_DIR}/ssl_scache
        SSLSessionCache         shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
        SSLSessionCacheTimeout  300

        #   Semaphore:
        #   Configure the path to the mutual exclusion semaphore the
        #   SSL engine uses internally for inter-process synchronization.
        #   (Disabled by default, the global Mutex directive consolidates by default
        #   this)
        #Mutex file:${APACHE_LOCK_DIR}/ssl_mutex ssl-cache

        #   SSL Cipher Suite:
        #   List the ciphers that the client is permitted to negotiate. See the
        #   ciphers(1) man page from the openssl package for list of all available
        #   options.
        #   Enable only secure ciphers:
        SSLCipherSuite HIGH:!aNULL

        # SSL server cipher order preference:
        # Use server priorities for cipher algorithm choice.
        # Clients may prefer lower grade encryption.  You should enable this
        # option if you want to enforce stronger encryption, and can afford
        # the CPU cost, and did not override SSLCipherSuite in a way that puts
        # insecure ciphers first.
        # Default: Off
        #SSLHonorCipherOrder on

        #   The protocols to enable.
        #   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
        #   SSL v2  is no longer supported
        SSLProtocol all -SSLv3

        #   Allow insecure renegotiation with clients which do not yet support the
        #   secure renegotiation protocol. Default: Off
        #SSLInsecureRenegotiation on

        #   Whether to forbid non-SNI clients to access name based virtual hosts.
        #   Default: Off
        #SSLStrictSNIVHostCheck On


Let's have a look at this file too:

also, try added to this file:

These two lines:

Protocols h2 http/1.1
SSLEngine On


# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

nacnud3000-le-ssl.conf has been updated.

Attempting to open the page under https still returns PR_END_OF_FILE_ERROR

Let's review all settings:
sudo apachectl -t -D DUMP_VHOSTS
sudo netstat -pant | grep -Ei '80|443|apache'

sudo apachectl -t -D DUMP_VHOSTS
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443 (/etc/apache2/sites-enabled/nacnud3000-le-ssl.conf:2)
*:80 (/etc/apache2/sites-enabled/nacnud3000.conf:1)

sudo netstat -pant | grep -Ei '80|443|apache'
tcp 0 0 TIME_WAIT -
tcp6 0 0 :::443 :::* LISTEN 7750/apache2
tcp6 0 0 :::80 :::* LISTEN 7750/apache2

That all seems... OK.

Can you confirm that port 443 is going to the same internal IP as port 80?

Yes, both 80 & 443 are pointing to the appropriate server address.

Well something doesn't add up...
Have you completely restarted the system?

And let's have one last look at the updated file:
sudo cat /etc/apache2/sites-enabled/nacnud3000-le-ssl.conf

Something is indeed not adding up.
I have restarted the system, router, and modem.
Started on a Raspberry Pi 4 on the same OS, tried with Raspbian x64 & x32 flavors.
Did a fresh setup on an older AMD x64 setup that is the machine now.
All encountering the same issues.
I've even tried a self signed cert manually setup to see if that had any change but I still encounter the same issues, the HDD was reformatted and a fresh install completed after that did not work.
My ISP does not block any ports and every test I've tried on the ports being able to get through pass.
I am considering a fresh OS re-install and giving NGINX a spin as I am not attached to using Apache and haven't tried that yet.

Only as a test:
Let's try using another port for SSL.
Find the "Listen 443" statement
[usually found in the "ports.conf" file]
And add another line to it.
Listen 9876
Then modify the line "<VirtualHost *:443>"
<VirtualHost *:9876>

restart apache and test:

That gets us somewhere.
Set ports.conf to listen on 9876.
Set nacnud3000-le-ssl.conf to 9876.
Allowed 9876 through UFW firewall.
Forwarded 9876 to server in router.
Restarted Apache
Going to is successful and using SSL.
Page Info in Firefox shows 'Connection Encrypted (TLS_AES_128_GCM_SHA256, 128 bit keys, TLS 1.3)' & verified by Let's Encrypt.
Changed all back to 443 & restart Apache, back to same issue.

Is it possible that while my ISP does not block ports they could be blocking the necessary protocols to allow the SSL handshake on 443?

Can you forward the external:443 to internal:9876 ?

If so, that should split this problem in two.

If it works, then the 443 problem is somewhere within your server.
[because everything outside of your server has remained the same].

If that still fails, then the 443 problem is somewhere outside your server.
[because everything outside of your server has remained the same].

Removed 9876 - 9876 from router forwarding.
Updated 443 - 9876 in router forwarding.
Refreshed & received same error on test.
Rebooted router, manually ran ddclient to update domain DNS info.
Verified updated DNS info active.
Test returns same error.