Site won't load at all after new cert

Help
1

Hi, I just set up a new certificate on a server that had no certificates. The process appeared to be a success, only I can’t get to my site at all now.

I can’t ping dev.co-brand2.com, and I can’t ping 52.73.108.54. I can still ssh in to either, though.

SSL Labs can’t find it either. I restarted Apache, and I even rebooted the machine. What’s going on?

My domain is: dev.co-brand2.com

I ran this command: sudo certbot --apache

It produced this output: Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/dev.co-brand2.com/fullchain.pem

My web server is (include version): Apache 2

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

2

Hi @3x5

your certificate is created:

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:dev.co-brand2.com&lu=cert_search

That part works.

Your http-server works:

download http://dev.co-brand2.com/ -h
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 317
Content-Type: text/html; charset=iso-8859-1
Date: Mon, 17 Sep 2018 23:07:58 GMT
Location: https://dev.co-brand2.com/
Server: Apache/2.4.18 (Ubuntu)

Status: 301 MovedPermanently
295,88 milliseconds
0,30 seconds

There is a redirect http -> https.

Perhaps you remove that redirect temporarily. But your https - version doesn't work.

Please share your apache-ssl-configuration.

3

Thanks for the reply. I’m not sure which file you want to see, but 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

        <Directory /var/www/html/redmine>
            RailsBaseURI /redmine
            PassengerResolveSymlinksInDocumentRoot on
        </Directory>
ServerName dev.co-brand2.com
SSLCertificateFile /etc/letsencrypt/live/dev.co-brand2.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/dev.co-brand2.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
4

Or do you want the contents of /etc/letsencrypt/options-ssl-apache.conf?

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC$
SSLHonorCipherOrder     on
SSLCompression          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

#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log

# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"
5

I suggest running ss -ntlp to find out whether Apache is listening on port 443. If so, the problem is a firewall policy forbidding inbound connections on port 443. (This seems like the most likely possibility to me.)

6

Thanks, I ran it and I have this line:

LISTEN 0 128 :::443 :::*

Doesn’t that meant it’s listening on port 443?

7

Yes, so that means that you have a firewall blocking it (either a local firewall like a ufw rule, or a network firewall like a hosting provider default policy).

1 Like
8

The ping application normally uses ICMP or UDP as protocols. It doesn't use TCP on port 80 (HTTP) or 443 (HTTPS) out of the box (you can specify a such on the command line though). certbot doesn't change firewall settings, nor does it change anything outside your webbrowser (in your case Apache). So the failure of ping doesn't have anything to do with certbot, at least, not by my knowledge.

1 Like
9

Thanks for the replies, everyone. This issue was indeed due to the proper ports not being open.

2 Likes
10

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