Renewing with TLS-SNI Challenge on Jetty Servers


#1

My certificate is due to expire in a few weeks time, and I’m trying to create a script to renew it. The only port I have open is port 443, with an HTTPS server listening to it using my current certificate. I use dynamic DNS, so it seems to me I can only use TLS verification.

As an experiment, I tried this to see what would happen (running as root):
certbot-auto renew --dry-run --preferred-challenges tls-sni-01 -v --standalone

This is what I got back:

The following errors were reported by the server:

Domain: mydomain.ddns.net
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
f5af9dac09f7e4e641ead1eb0c5f805b.f2adfa9d6fcbcf6937b185b5a6d8b763.acme.invalid
from xxx.xxx.xxx.xxx:443. Received 2 certificate(s), first
certificate had names “mydomain.ddns.net

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

Can anyone tell me what is going on here? (The DNS records are correct, I can connect to my site, and I get my existing certificate when I do, BTW.)


#2

Hi @PRH,

--standalone expects you to shut down your existing web server before running. It should have displayed an error about this, so that’s weird that it didn’t, but in any case this seems to be a symptom of leaving your existing server running while running Certbot with --standalone.


#3

Yes, after I posted I realised that a new server trying to attach to 443 wouldn’t work very well…

But it’s a real pain – I have people who depend on the server being available, I never shut it down if I can help it, and if I have to I do it as a restart at about 3am with a cron job. It’s probably easier to open port 80 for a few minutes while I renew and then close it again.

What this means is that it’s impossible for me to automate the renewal process as I was planning. The ideal way would be to have the option of using TLS with --webroot… are there any plans to do this?

It seems a bit silly to provide people with certificates so they can provide an HTTPS server and then not provide any way to update it via HTTPS without shutting down the server!


#4

Hi @PRH,

There are three validation methods provided by ACME: TLS-01 (which requires speaking TLS on port 443), HTTP-01 (which requires speaking HTTP on port 80), and DNS-01 (which requires setting a certain DNS record in your DNS zone). The ACME spec requires these specific TCP port numbers, as a result of some security considerations discussed in the ACME working group at IETF.

Each of them can potentially be used with an existing server without stopping it. For TLS-01 there are --apache and --nginx (the latter still considered experimental), which will try to reconfigure existing Apache or Nginx servers to serve the appropriate certificates; for HTTP-01 there’s --webroot; and for DNS-01 there’s --manual (and more extensive support in some of the other Let’s Encrypt clients).

The --apache and --nginx methods require a reload, but not a stop, on the web server.


#5

But alas, I’m using Jetty.

I would have thought the same technique used for HTTP-01 by --webroot would be equally applicable to TLS-01 (creating a specific file containing a nonce inside the web hierarchy). It would make a lot of sense to have this, since we’re dealing with certificates intended to encourage more people to migrate to HTTPS. And it would allow me to script my certificate renewal to happen automatically.

So I ask again: do Letsencrypt have any plans to add this valuable feature?


#6

hi @PRH

Why not use the DNS challenge?

You can automate the creation of TXT records

There is currently not plugin for jetty but you can write one yourself

People also open up port 80 temporarily on their firewall to do the renewal as well.

So you are spoilt for choices really on making the challenges work.

Andrei


#7

I’m using dynamic DNS, so I don’t think I can.

I opened port 80 and did the renewal that way – but it means renewing manually every time. I had hoped to automate it, but it doesn’t seem I can…


#8

the only option i see is to have a pre-hook and post-hook

if your firewall supports API calls you can use this to automate the renewals

what firewall are you running?

Andrei


#9

The firewall is on my router which has a built-in web server as the control panel. I suppose I could hand-craft some HTTP requests to open and close the port but it doesn’t seem worth the hassle at this point. If nothing changes at the letsencrypt end to make my life easier I might get off my backside and do this, but not yet.

So meantime, once every two or three months, I can open the port, renew, and close it again. From that point on everything is automated – when the certificate date changes, a cron job runs at 3am to build a new JKS keystore, backup and replace the existing keystore, and then restart the server. (It’s also supposed to be possible to get Jetty to reload the new keystore dynamically to avoid restarting at all, but I haven’t managed to get that to work…)

I was going to run the renewal as part of the 3am cron as well, with a post-hook to do all the rest, but… oh well.

Meantime, feature request to letsencrypt: PLEASE, guys, if you’re in the business of issuing certificates to encourage people to use HTTPS instead of plaintext HTTP, PLEASE add support for renewal using --webroot on the HTTPS server that the certificate was issued to support!


#10

Hi @PRH,

There was a long discussion in the IETF ACME working group about a proposed HTTPS-01 challenge type which was parallel to HTTP-01 (changing a file served over that protocol). Unfortunately, this method was explicitly rejected by the working group because of security concerns, which I believe had to do with a common default behavior in shared hosting environments that would allow people to get certs for other customers’ domains. So, it won’t be added in its current form.

The particular validation methods that we have are the result of pretty long discussions both at the CA/Browser Forum and IETF, which include a lot of discussion of what could go wrong (typically in shared web hosting environments) with additional methods, so it’s not very simple to add new ones.


#11

OK, glad to hear that there’s a good reason at the back of it somewhere (although I’m still curious as to what the potential security risk is?).

I suppose now I just have to hope that someone develops a Jetty plugin to go alongside the Apache/Nginx ones. (And of course to think about scripting HTTP requests to my router to open & close port 80 in the meantime…)


#12

@schoen would it be possible to use --standalone in http-01 mode and have it bind only to port 80? That would address the issue here - since it sounds like they don’t have anything running on port 80.


#13

Exactly what I did, but I normally don’t have port 80 open, so I had to open it beforehand and close it afterwards.


#14

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