How to get a certificate, without using port 80?

Help
1

I have an old Debian Wheezy system, for which I need a certificate for Postfix and Courier (imap). There is an Apache webserver running, and only port 443 (not 80) is open in the firewall.
I’ve tried using both certbot-auto and getssl, but they both seem to advertise a ‘http:’//’ url to validate, which fails.

How can I force the webroot plugin to use https, or is there another plugin for certbot that is more suitable for my needs?

In getssl I’ve set CHALLENGE_CHECK_TYPE=“https”, but it still tries to connect to http.

2

I’m sitting here with kinda the same problem.
I got my regular websites und my-domain.au, shop.my-domain.au, admin.my-domain.eu and they all sit in the same webroot. For those i have no problem when i try to get certificates for those domains.
I have another subdomain mail.my-domain.au and the webroot of that is the roundcube installation. I just can’T seem to get certificates for it because http gets redirected to https when entering mail.my-domain.au. So how can i get a certificate for mail.my-domain.au although it’s https only?

3

The only way to force the webroot plugin to use https is to configure your server to respond to the http request with a redirect (which means you still need port 80 open).

If you want to use port 443 only, you can use the apache, nginx (I think) or standalone plugins instead of webroot. You might need to specify --preferred-challenges tls-sni.

You can also use the dns challenge, which doesn’t require any ports.

4

As Apache is already listening on port 443, I think only the Apache plugin would apply, but unfortunately that one does seem to need a more recent version of augeas than is available in Debian Wheezy.
Also, I don’t really want automatic updates in my Apache configuration, which relies a lot on macros.

DNS is at the moment hosted externally, so not really an option.

5

Are there other clients besides certbot or getssl I should look at, that may solve my problem?

6

No. Your problem is that whatever client you use must do one of three things to validate control over your hostname:

  • It must respond appropriately to a request for http://$HOSTNAME/.well-known/acme-challenge/...
  • It must respond appropriately (i.e., with an appropriate self-signed TLS certificate) to https://$HOSTNAME
  • It must (or, alternatively, you must manually) change your DNS records to add a specified TXT record.

If you're unable or unwilling to allow the client to do any of those three, then you won't be able to obtain a cert from Let's Encrypt. Note, though, that external DNS is not (or, at least, not necessarily) an issue--many DNS hosts have APIs that you can use to automate the validation process.

2 Likes
7

Is it possible to request https auth to an alternate port (not 443)?
Assuming there is another port allowed through the firewall.

8

Nope, this is forbidden by the ACME specification and partially forbidden (well, significantly restricted) by CA/Browser Forum rules.

9

Of the 3 options, using tls-sni may have been an option for me, by running certbot in standalone mode, on an alternative port, and then redirect traffic originating from letsencrypt to that port, but then I would have to guess what IP address letsencrypt is using.

Instead, I decided to adjust my Apache configuration a little, so that it is also usable on port 80, and open and close the firewall port in a script that also runs certbot in webroot mode. This works for me, after I automate it a little bit more :slight_smile:

10

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