Renewing via port 443

Issuance Tech
1

I don’t understand why it’s necessary to have port 80 open to renew a LetsEncrypt certificate, particularly if the certificate has not yet expired.

So every few months I have to unblock port 80 on my firewall so that I can renew the certificate.

What’s the reason for this restriction?

4 Likes
2

There are rules set by the CA|B forum.

There are many reasons to leave port 80 open:

There are also other challenge types (for those who can’t use port 80):

6 Likes
3

You used to be able to complete challenges via port 443 (with plain HTTPS protocol), it’s just that there was quite a severe security vulnerable discovered, allowing people to create certificates for domains they don’t own, which made that practice untenable.

You can still use port 443 to complete challenges, but it requires implementing the TLS-ALPN challenge, which simply isn’t supported by the majority of e.g. Apache and nginx deployments.

Caddy is one such server that supports it.

If you have a very new version of Apache, you can also use the mod_md module which also supports TLS-ALPN.

You can also stop your server, use a Let’s Encrypt client like acme.sh that will create a TLS-ALPN server on port 443, issue your certificate, and start it again all automatically:

acme.sh --issue --alpn -d example.com \
--pre-hook "service apache2 stop" \
--post-hook "service apache2 start"

Everybody wishes that port 443 completion of challenges was simpler but there wasn’t a way identified to do it sufficiently securely.

Also, https://letsencrypt.org/docs/allow-port-80/

9 Likes
4

Now that this side of the “argument/debate” is clear…
If you care to continue the discussion: What are you reasons for NOT wanting to use port 80 (ever)?
[no one hates HTTP more than I (^see my logo) - but I think we can come to some consensus here]

2 Likes
5

Using the DNS-01 challenge type will allow you to obtain a certificate without opening any ports, even 443.

2 Likes
6

Single static IP address, port 443 goes to a private cloud server where people can upload documents securely. I would prefer that people can’t make connections to it by mistake using insecure protocol. I prefer to trust my firewall’s ability to just block port 80 than making sure that rewrite rules don’t have any holes. I also wouldn’t mind having a second web server for stuff that doesn’t need to be secure, e.g., family photos, blog articles, etc and then my firewall would route incoming port 80 connects to that second server.

1 Like
7

Thanks everyone for all the response, I appreciate them.

1 Like
8

This is one of the things HTTP Strict Transport Security (HSTS) is designed to help with. You might be interested in researching it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

3 Likes
10

You can simple create one vhost config block that basically just says:
“There is NO HTTP server here, go to HTTPS - (except for any challenge requests)”
[modify to fit your needs]

#NGINX sample code
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name  _;
    location /.well-known/acme-challenge/ {
       try_files $uri =404;
    }#location
    return 301 https://$host$request_uri;
}#server

And if you are super paranoid, you can send the port 80 connections to a separate system (not to the same one that does port 443).
Then proxy only the challenge requests from the “80 only system” to the “443 only system”.
If you are insane about security, then place an IPS between the “80 only system” and the “443 only system” to insure no funny business is going on.
If that still keeps you up at night… talk to my friends Jack and Johnny and the good o’le Captain.

3 Likes
11

Thank you — those are excellent suggestions.

3 Likes
12

I do not exactly understand these suggestions. I am having problems renewing an expired certificate. How do I integrate this into my configuration file? Mine looks quite different btw

server {
listen 80;
server_name nextcloud.somewhere.it;
return 301 https://nextcloud.somewhere.it$request_uri;
}

server {
listen 443 ssl http2; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/nextcloud.somewhere.it/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/nextcloud.somewhere.it/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

server_name nextcloud.somewhere.it;

# Add headers to serve security related headers
add_header Strict-Transport-Security "max-age=20" always;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;

I have tried many things but renewing fails every time. I do miss important background knowledge here I must admit, but I think it has to do with the expired certificate and renewing will not connect to port 443 without it?

13

I doesn't look that different.
Just add the location section:

server {
  listen 80;
  server_name nextcloud.somewhere.it;
  location /.well-known/acme-challenge/ {
    try_files $uri =404;
  }#location
  return 301 https://nextcloud.somewhere.it$request_uri;
}#server
1 Like
14

Thank you very much for clearing that up. I have integrated the “location” line. Renewing certificate still does not work. What should I do? Server error is - Timeout during connect (likely firewall problem) - But my firewall has the “Nginx Full” program profile enabled, which opens ports 80 and 443. I THINK it has to do with the certificate for port 443 being expired is the problem, but I might be wrong about that. What steps could I undertake to troubleshoot?

15

Make a proper start by opening a new topic and provide all the information requested.

2 Likes
16

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