Increasing tls-sni-01 server timeout

You can have it listen on any port, but Let’s Encrypt will only send it over 443

The scenario I am talking about has n individual devices wanting to be externally accessible under their own DNS.

So for example, a device behind NAT, “group1.home.warmcat.com”, might have his own :443 port-forwarded to be externally accessible at :1443. He wants to acquire and manage his own cert for “group1.home.warmcat.com” all from external port :1443, without involving whatever might get the external portforward for :443.

draft-ietf-acme-acme-01 doesn’t seem to have a problem with that.

The reason for this is to provide an alternative to “all your IoT devices send all your data to someone else’s server so you can access it with a valid tls cert”.

Certificate on the requested FQDN which is accessible to the CA via TLS over port 443.

Thanks… right now with ACME and LE and boulder implementation variations it is difficult to know what applies…

If the IETF versions will allow other ports, hopefully LE will also allow it. I can get where they’re coming from that :443 is the only guy that is authoritative to bless the request for a cert that will be used on :443. But there is nothing about certificates that lock them to any specific port.

Let’s Encrypt also has to comply with the CA/Browser Forum’s Baseline Requirements (note the BR reference in the CPS). That specifies that it must use an “Authorized Port” which is defined elsewhere in the document to mean 80, 443, 115, 25 or 22. So the options available are quite limited anyway, even if LE were to allow all of them, and that still wouldn’t really help for your use case.

it must use an “Authorized Port” which is defined elsewhere in the document to mean 80, 443, 115, 25 or 22.

Thanks.

I can think of some ideas to workaround that but nothing really useful atm.

Another possible (?) solution to this problem might be to provide a parent domain on the PSL and allow the devices to register subdomains and use the DNS-01 challenge to obtain their certificates. That’s likely to be less resource-hungry too, I’d imagine.

1 Like

Could you describe how these devices will be used in practice? Here’s a great blog post on how Plex deployed HTTPS for their IoT-like servers, there’s a good chance their approach could work for your use-case: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

Something like this could be built on top of Let’s Encrypt. I’m not aware of any existing projects that solve this exact problem, but acme-dns might be a good starting point.

(Side note: Later ACME drafts (such as acme-08) clarified that the ports used for the HTTP and TLS-SNI challenges are 80 and 443, to avoid this type of confusion.)

1 Like

provide a parent domain on the PSL

Thanks, I will take a look.

Could you describe how these devices will be used in practice?

These ESP32 modules are very cheap (US$3.50 http://www.electrodragon.com/product/wroom-32/ ) and very capable.

I am providing generic LGPL2 + SLE support for them in libwebsockets, I have two use-cases myself, one design is an isolated UART <-> WIFI supporting 1.8V and 3.3V, and the other is an isolated switch with voltage and current monitoring, again over WIFI.

The UART design is accessible over ssh, telnet and browser; for ssh you set it up with the browser and paste your public ssh key into a form.

The modules bind together by using a “group” name with mdns locally, so if you access one in a browser you get a list of devices in the same group with their UI in individual iframes.

The devices produce a selfsigned cert automatically when first booted. So if you have several devices in your group, each browser that wants to access them faces a bunch of selfsigned cert browser UI noise… browsers like Firefox for Android just ban selfsigned as far as I can tell with no accept UI presented. So this is very messy.

If they can each acquire and maintain a valid cert replacing the initial selfsigned one, and behind the NAT the cert DNS name resolves to the correct local IP for the device, that will remove all the problems. Implementing that the way I was following until now also requires individual portforwards to the devices, even if that is only used to reply to the tls-sni-01 challenges.

Better ideas are welcome :slight_smile: I think it’s a general problem that before Let’s Encrypt had no way for the certificate infrastructure to solve neatly.

Hi again @warmcat,

Apologies on dropping off this thread. It’s been a busy week :slight_smile:

So unless I continue to misunderstand it, it seems to still boil down to needing a timeout extension.

I’ll discuss with the other two Boulder engineers whether an adjustment to this timeout is reasonable. It might require tweaking a few other timeouts down the callpath to ensure that the RPCs involved in performing validation don’t time out before the validation request.

Do you think that a 10s timeout would give your devices enough headroom to complete the required handshakes?

I don’t think its likely we would relax this restriction on our end. In practice there’s all manner of strange configurations in the wild and historically its hard to make assumptions about which ports are safe to assume can authoritatively speak for a domain in a way that won’t result in any misissuance. Between HTTP-01, TLS-SNI-01 and DNS-01 there’s a pretty good selection of options available that should work for most cases without needing additional challenge ports.

Do you think that a 10s timeout would give your devices enough headroom to complete the required handshakes?

Thanks for the reply. I think so. It seems the best I can do in 5s is complete the tls handshake to 3 of the 4, with the timing of issuing the challenges you discovered I am getting. I don’t get feedback about that though from the server, just the same “timeout” from the one that failed, all I see is we completed them our side before it sends EOF / hangs up on us, except for the last one. I have tried yesterday using the second core on ESP32 to run a second tls accept in parallel, but this doesn’t help much since only one thread can use the crypto acceleration at a time and it’s the signing part of the handshake that takes most of the time (since 2048-bit RSA is mandated by the server, somewhat needlessly in this case since the token is either in the cert’s SAN or not, and the cert is selfsigned).

I don’t think its likely we would relax this restriction on our end

I understood from this thread this is externally mandated, so no point arguing to ignore that. And I understand it’s the job here to err on the side of being conservative. However there is a sort of problem of definition there, coming from X.509 or whatever defined common usage of the CN, certs themselves have no affinity to specific ports. :443 should be especially authoritative for a cert aimed to be used on :443, but it has no inherent authority for a cert intended for use on another port; all issued certs work on any port. Ports below 1024 equally imply the admin set up the listener or at least admins the router (and as such can direct :443 anywhere too).

It’s just an observation: my plan needed the challenge to come on any port which I realize from the discussion isn’t the direction things are going in and you don’t have a free hand to do it even if you wanted to.

Between HTTP-01, TLS-SNI-01 and DNS-01 there’s a pretty good selection of options available that should work for most cases without needing additional challenge ports.

That is true for the scenario of an IP’s single https server aquiring the cert. If something already occupies :443 and :80 and something else wants a cert, it’s beyond home users to configure the DNS challenge I think.

Anyway thanks for considering increasing the timeout, it will be very helpful.

Interesting use case! My recommendation is to use HTTP-01 instead of TLS-SNI-01, to save the multiple-TLS-connection overhead. I realize people will need to set up multiple port forwards, and that’s less convenient, but if they’re setting up one, it should be possible to set up two. The big advantage of making port 80 available in your app is that you can serve an automatic redirect to HTTPS. Since your goal is to provide a very easy-to-use service, I think that’s pretty valuable.

Unfortunately, I think there isn’t a good way to multiplex validation access to multiple hosts behind the firewall.

My recommendation is to use HTTP-01

External :443 and :80 are scarce resources also for the home user, if he’s sophisticated he probably already has something serving on them, eg either forwarded to another box or Lede/Openwrt or so and :80 redirects to :443. Then it’s not a matter of port-forwarding any more, it’s a conflict of uses on the external port.

I understand LE has had just one usecase in mind which is https servers on :443 getting certs for themselves, that’s obviously a very valuable thing that didn’t exist before. But the reasonable answers for that usecase don’t apply to anything else, even if it’s eg, getting a cert for IMAP automagically. Whatever is behind :443 is not inherently authoritative for Dovecot on a different box. But the cert if issued is definitively authoritative for any port on the IP the CN resolves to. That’s really the same set of issues as the “IoT devices behind NAT”.

In the case there is more than one device that wants to do this (the modules are extremely cheap), and he wants to auto-renew, even if :80 is free it doesn’t help, since it can only be told to point to one thing at a time. Then anything else than pointed to cannot auto-renew.

As I mentioned it seems at heart an X.509 CN issue. If the CN was commonly interpreted that the cert could only apply to a specific port (eg, the cert CN was “myserver.com:1234”) then there would presumably be less concern about negotiating with “myserver.com:1234” for the challenge if the cert only worked on myserver.com:1234.

Another way might be via wildcard certs somehow, you manually get a wildcard cert and provision the same cert to all devices. But there would need to be a story for securely getting the renewed cert from somewhere.

If we’re going to get technical, CN is deprecated, and relying parties should not look at it. Everything has to be in Subject Alternative Names these days. :slight_smile:

There’s a newer standard for this sort of thing, called SRVName: https://tools.ietf.org/html/rfc4985. AFAIK it’s not yet allowed by the BRs.

As was pointed out above, and you acknowledged, this is largely out of our hands; the Baseline Requirements don’t allow us to validate arbitrary ports, even if we felt it was safe to do so.

In theory things get better in an IPv6 world, since each device in the home is individually addressable, but you’d still need people to poke holes in their firewall for those devices.

1 Like

As was pointed out above, and you acknowledged, this is largely out of our hands; the Baseline Requirements don’t allow us to validate arbitrary ports, even if we felt it was safe to do so.

Yes… all I am asking for is the 10s timeout, which is under your control.

That will let at least a single, port-forwarded ESP32 complete tls-sni-01 / -02.

The rest of the meta stuff here will need further thought / intercession elsewhere.

You’ve won us over on this front (edit: Opened https://github.com/letsencrypt/boulder/pull/3260). I’m going to work on changing the timeout this week and will update on here once staging is updated.

1 Like

This change went out to the staging environment this afternoon. The validation authority’s single dial timeout is now 10s instead of 5s.

1 Like

Thanks a lot guys.

It can complete the whole thing now… I was initially confused by the success, because afterwards with the cached auth keys, it just skipped to giving me the cert again without doing the challenges. I removed the keys and ran it again with the second core stuff disabled (and restricted to accepting 3 x tls connections at a time, effectively that’s 2 challenges in parallel since the third is occupied with a ws link)

[2017/12/06 01:58:36:2847] NOTICE: _realloc: size 560: new server wsi (free heap 123056)
[2017/12/06 01:58:36:2881] NOTICE: Running wsi 0x3ffdfd04 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:36:2917] NOTICE: mbedtls_handshake: ssl ret 0 state 1
[2017/12/06 01:58:36:3001] NOTICE: lws_mbedtls_sni_cb: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid
[2017/12/06 01:58:36:3117] NOTICE: SNI: Found: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid:443 at vhost '6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid'
[2017/12/06 01:58:36:3320] NOTICE: mbedtls_handshake: ssl ret 0 state 2
[2017/12/06 01:58:36:3423] NOTICE: mbedtls_handshake: ssl ret 0 state 3
[2017/12/06 01:58:36:3488] NOTICE: mbedtls_handshake: ssl ret 0 state 4
[2017/12/06 01:58:36:3532] NOTICE: ssl_write_server_key_exchange
[2017/12/06 01:58:36:3598] NOTICE: ECDHE curve: secp384r1
[2017/12/06 01:58:36:3660] NOTICE: ssl_write_server_key_exchange: ecdhe make params
[2017/12/06 01:58:36:8912] NOTICE: ssl_write_server_key_exchange: uses server sig
[2017/12/06 01:58:36:8920] NOTICE: ssl_write_server_key_exchange: compute hash 1.2
[2017/12/06 01:58:36:8977] NOTICE: ssl_write_server_key_exchange: compute hash 1.2 done
[2017/12/06 01:58:36:9058] NOTICE: ssl_write_server_key_exchange: pk sign start
[2017/12/06 01:58:37:5764] NOTICE: ssl_write_server_key_exchange: pk sign end
[2017/12/06 01:58:37:5804] NOTICE: mbedtls_handshake: ssl ret 0 state 5
[2017/12/06 01:58:37:5811] NOTICE: mbedtls_handshake: ssl ret 0 state 6
[2017/12/06 01:58:37:5906] NOTICE: mbedtls_handshake: ssl ret 0 state 7
[2017/12/06 01:58:37:5956] NOTICE: mbedtls_handshake: ssl ret 0 state 8
[2017/12/06 01:58:37:6034] NOTICE: mbedtls_handshake: ssl ret -26880 state 8
[2017/12/06 01:58:37:6106] NOTICE: lws_tls_server_accept: 0x3ffdfd04: accept SSL_get_error 5 errno 11
[2017/12/06 01:58:37:6205] NOTICE: _realloc: size 996: ah struct (free heap 94508)
[2017/12/06 01:58:37:6285] NOTICE: _realloc: size 1024: ah data (free heap 93480)
[2017/12/06 01:58:37:6382] NOTICE: _realloc: size 560: new server wsi (free heap 92832)
[2017/12/06 01:58:37:6500] NOTICE: lws_gate_accepts: on = 0
[2017/12/06 01:58:37:6517] NOTICE: Running wsi 0x3ffe9938 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:37:6603] NOTICE: mbedtls_handshake: ssl ret 0 state 1
[2017/12/06 01:58:37:6690] NOTICE: lws_mbedtls_sni_cb: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid
[2017/12/06 01:58:37:6801] NOTICE: SNI: Found: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid:443 at vhost '6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid'
[2017/12/06 01:58:37:7005] NOTICE: mbedtls_handshake: ssl ret 0 state 2
[2017/12/06 01:58:37:7114] NOTICE: mbedtls_handshake: ssl ret 0 state 3
[2017/12/06 01:58:37:7187] NOTICE: mbedtls_handshake: ssl ret 0 state 4
[2017/12/06 01:58:37:7218] NOTICE: ssl_write_server_key_exchange
[2017/12/06 01:58:37:7284] NOTICE: ECDHE curve: secp384r1
[2017/12/06 01:58:37:7345] NOTICE: ssl_write_server_key_exchange: ecdhe make params
[2017/12/06 01:58:38:3463] NOTICE: ssl_write_server_key_exchange: uses server sig
[2017/12/06 01:58:38:3471] NOTICE: ssl_write_server_key_exchange: compute hash 1.2
[2017/12/06 01:58:38:3528] NOTICE: ssl_write_server_key_exchange: compute hash 1.2 done
[2017/12/06 01:58:38:3611] NOTICE: ssl_write_server_key_exchange: pk sign start
[2017/12/06 01:58:38:6792] NOTICE: ssl_write_server_key_exchange: pk sign end
[2017/12/06 01:58:38:6845] NOTICE: mbedtls_handshake: ssl ret 0 state 5
[2017/12/06 01:58:38:6852] NOTICE: mbedtls_handshake: ssl ret 0 state 6
[2017/12/06 01:58:38:6933] NOTICE: mbedtls_handshake: ssl ret 0 state 7
[2017/12/06 01:58:38:6983] NOTICE: mbedtls_handshake: ssl ret 0 state 8
[2017/12/06 01:58:38:7061] NOTICE: mbedtls_handshake: ssl ret -26880 state 8
[2017/12/06 01:58:38:7133] NOTICE: lws_tls_server_accept: 0x3ffe9938: accept SSL_get_error 5 errno 11
[2017/12/06 01:58:38:7232] NOTICE: _realloc: size 996: ah struct (free heap 69288)
[2017/12/06 01:58:38:7313] NOTICE: _realloc: size 1024: ah data (free heap 68260)
[2017/12/06 01:58:38:7400] NOTICE:  heap :68256 (-54252)
[2017/12/06 01:58:38:7456] NOTICE: Running wsi 0x3ffdfd04 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:39:3432] NOTICE: mbedtls_handshake: ssl ret 0 state 9
[2017/12/06 01:58:39:3439] NOTICE: mbedtls_handshake: ssl ret 0 state 10
[2017/12/06 01:58:39:3480] NOTICE: mbedtls_handshake: ssl ret 0 state 11
[2017/12/06 01:58:39:3571] NOTICE: mbedtls_handshake: ssl ret 0 state 12
[2017/12/06 01:58:39:3653] NOTICE: mbedtls_handshake: ssl ret 0 state 13
[2017/12/06 01:58:39:3744] NOTICE: mbedtls_handshake: ssl ret 0 state 14
[2017/12/06 01:58:39:3767] NOTICE: mbedtls_handshake: ssl ret 0 state 15
[2017/12/06 01:58:39:3848] NOTICE: mbedtls_handshake: ssl ret 0 state 16
[2017/12/06 01:58:39:3922] NOTICE:  heap :74196 (+5940)
[2017/12/06 01:58:39:3978] NOTICE: Running wsi 0x3ffe9938 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:39:9306] NOTICE: mbedtls_handshake: ssl ret 0 state 9
[2017/12/06 01:58:39:9313] NOTICE: mbedtls_handshake: ssl ret 0 state 10
[2017/12/06 01:58:39:9354] NOTICE: mbedtls_handshake: ssl ret 0 state 11
[2017/12/06 01:58:39:9443] NOTICE: mbedtls_handshake: ssl ret 0 state 12
[2017/12/06 01:58:39:9526] NOTICE: mbedtls_handshake: ssl ret 0 state 13
[2017/12/06 01:58:39:9618] NOTICE: mbedtls_handshake: ssl ret 0 state 14
[2017/12/06 01:58:39:9642] NOTICE: mbedtls_handshake: ssl ret 0 state 15
[2017/12/06 01:58:39:9720] NOTICE: mbedtls_handshake: ssl ret 0 state 16
[2017/12/06 01:58:39:9865] NOTICE: lws_gate_accepts: on = 1
[2017/12/06 01:58:39:9890] NOTICE: _realloc: size 560: new server wsi (free heap 96996)
[2017/12/06 01:58:39:9962] NOTICE: lws_gate_accepts: on = 0
[2017/12/06 01:58:39:9999] NOTICE: Running wsi 0x3ffdfd04 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:40:0092] NOTICE: mbedtls_handshake: ssl ret 0 state 1
[2017/12/06 01:58:40:0169] NOTICE: lws_mbedtls_sni_cb: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid
[2017/12/06 01:58:40:0284] NOTICE: SNI: Found: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid:443 at vhost '6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid'
[2017/12/06 01:58:40:0489] NOTICE: mbedtls_handshake: ssl ret 0 state 2
[2017/12/06 01:58:40:0590] NOTICE: mbedtls_handshake: ssl ret 0 state 3
[2017/12/06 01:58:40:0655] NOTICE: mbedtls_handshake: ssl ret 0 state 4
[2017/12/06 01:58:40:0702] NOTICE: ssl_write_server_key_exchange
[2017/12/06 01:58:40:0767] NOTICE: ECDHE curve: secp384r1
[2017/12/06 01:58:40:0828] NOTICE: ssl_write_server_key_exchange: ecdhe make params
[2017/12/06 01:58:40:6337] NOTICE: ssl_write_server_key_exchange: uses server sig
[2017/12/06 01:58:40:6345] NOTICE: ssl_write_server_key_exchange: compute hash 1.2
[2017/12/06 01:58:40:6403] NOTICE: ssl_write_server_key_exchange: compute hash 1.2 done
[2017/12/06 01:58:40:6483] NOTICE: ssl_write_server_key_exchange: pk sign start
[2017/12/06 01:58:40:9631] NOTICE: ssl_write_server_key_exchange: pk sign end
[2017/12/06 01:58:40:9674] NOTICE: mbedtls_handshake: ssl ret 0 state 5
[2017/12/06 01:58:40:9680] NOTICE: mbedtls_handshake: ssl ret 0 state 6
[2017/12/06 01:58:40:9770] NOTICE: mbedtls_handshake: ssl ret 0 state 7
[2017/12/06 01:58:40:9823] NOTICE: mbedtls_handshake: ssl ret 0 state 8
[2017/12/06 01:58:40:9900] NOTICE: mbedtls_handshake: ssl ret -26880 state 8
[2017/12/06 01:58:40:9972] NOTICE: lws_tls_server_accept: 0x3ffdfd04: accept SSL_get_error 5 errno 11
[2017/12/06 01:58:41:0071] NOTICE: _realloc: size 996: ah struct (free heap 76080)
[2017/12/06 01:58:41:0151] NOTICE: _realloc: size 1024: ah data (free heap 75052)
[2017/12/06 01:58:41:0239] NOTICE:  heap :75048 (+852)
[2017/12/06 01:58:41:0369] NOTICE: lws_gate_accepts: on = 1
[2017/12/06 01:58:41:0393] NOTICE: _realloc: size 560: new server wsi (free heap 91720)
[2017/12/06 01:58:41:0478] NOTICE: lws_gate_accepts: on = 0
[2017/12/06 01:58:41:0503] NOTICE: Running wsi 0x3ffef830 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:41:0589] NOTICE: mbedtls_handshake: ssl ret 0 state 1
[2017/12/06 01:58:41:0677] NOTICE: lws_mbedtls_sni_cb: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid
[2017/12/06 01:58:41:0787] NOTICE: SNI: Found: 6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid:443 at vhost '6d642b7dc90dcaa2b41019f4daeb7d2f.15caba380307380af6707a43ea29872b.acme.invalid'
[2017/12/06 01:58:41:0992] NOTICE: mbedtls_handshake: ssl ret 0 state 2
[2017/12/06 01:58:41:1101] NOTICE: mbedtls_handshake: ssl ret 0 state 3
[2017/12/06 01:58:41:1167] NOTICE: mbedtls_handshake: ssl ret 0 state 4
[2017/12/06 01:58:41:1204] NOTICE: ssl_write_server_key_exchange
[2017/12/06 01:58:41:1270] NOTICE: ECDHE curve: secp384r1
[2017/12/06 01:58:41:1333] NOTICE: ssl_write_server_key_exchange: ecdhe make params
[2017/12/06 01:58:41:7495] NOTICE: ssl_write_server_key_exchange: uses server sig
[2017/12/06 01:58:41:7503] NOTICE: ssl_write_server_key_exchange: compute hash 1.2
[2017/12/06 01:58:41:7561] NOTICE: ssl_write_server_key_exchange: compute hash 1.2 done
[2017/12/06 01:58:41:7642] NOTICE: ssl_write_server_key_exchange: pk sign start
[2017/12/06 01:58:42:0801] NOTICE: ssl_write_server_key_exchange: pk sign end
[2017/12/06 01:58:42:0854] NOTICE: mbedtls_handshake: ssl ret 0 state 5
[2017/12/06 01:58:42:0860] NOTICE: mbedtls_handshake: ssl ret 0 state 6
[2017/12/06 01:58:42:0942] NOTICE: mbedtls_handshake: ssl ret 0 state 7
[2017/12/06 01:58:42:0992] NOTICE: mbedtls_handshake: ssl ret 0 state 8
[2017/12/06 01:58:42:1070] NOTICE: mbedtls_handshake: ssl ret -26880 state 8
[2017/12/06 01:58:42:1142] NOTICE: lws_tls_server_accept: 0x3ffef830: accept SSL_get_error 5 errno 11
[2017/12/06 01:58:42:1242] NOTICE: _realloc: size 996: ah struct (free heap 70640)
[2017/12/06 01:58:42:1322] NOTICE: _realloc: size 1024: ah data (free heap 69612)
[2017/12/06 01:58:42:1409] NOTICE:  heap :69608 (-5440)
[2017/12/06 01:58:42:1465] NOTICE: Running wsi 0x3ffdfd04 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:42:7672] NOTICE: mbedtls_handshake: ssl ret 0 state 9
[2017/12/06 01:58:42:7679] NOTICE: mbedtls_handshake: ssl ret 0 state 10
[2017/12/06 01:58:42:7722] NOTICE: mbedtls_handshake: ssl ret 0 state 11
[2017/12/06 01:58:42:7813] NOTICE: mbedtls_handshake: ssl ret 0 state 12
[2017/12/06 01:58:42:7893] NOTICE: mbedtls_handshake: ssl ret 0 state 13
[2017/12/06 01:58:42:8003] NOTICE: mbedtls_handshake: ssl ret 0 state 14
[2017/12/06 01:58:42:8010] NOTICE: mbedtls_handshake: ssl ret 0 state 15
[2017/12/06 01:58:42:8087] NOTICE: mbedtls_handshake: ssl ret 0 state 16
[2017/12/06 01:58:42:8168] NOTICE: Running wsi 0x3ffef830 accept in fg
ssl_pm_handshake
[2017/12/06 01:58:43:3686] NOTICE: mbedtls_handshake: ssl ret 0 state 9
[2017/12/06 01:58:43:3694] NOTICE: mbedtls_handshake: ssl ret 0 state 10
[2017/12/06 01:58:43:3734] NOTICE: mbedtls_handshake: ssl ret 0 state 11
[2017/12/06 01:58:43:3823] NOTICE: mbedtls_handshake: ssl ret 0 state 12
[2017/12/06 01:58:43:3907] NOTICE: mbedtls_handshake: ssl ret 0 state 13
[2017/12/06 01:58:43:3984] NOTICE: mbedtls_handshake: ssl ret 0 state 14
[2017/12/06 01:58:43:4022] NOTICE: mbedtls_handshake: ssl ret 0 state 15
[2017/12/06 01:58:43:4101] NOTICE: mbedtls_handshake: ssl ret 0 state 16
[2017/12/06 01:58:43:4175] NOTICE:  heap :81720 (+12112)
[2017/12/06 01:58:43:4311] NOTICE: lws_gate_accepts: on = 1
[2017/12/06 01:58:44:0048] NOTICE:  heap :121448 (+39728)

It completed the challenged by 43.431, starting at 36.284, so around 7.2s.

The next thing is a deferred client connection to check the result

[2017/12/06 01:58:45:0049] NOTICE: _realloc: size 560: cbwsi (free heap 122660)
[2017/12/06 01:58:45:0056] NOTICE: timed cb: vh ap, protocol lws-acme-client, reason 45083
[2017/12/06 01:58:45:0114] NOTICE: _realloc: size 560: client wsi (free heap 122096)
[2017/12/06 01:58:45:0197] NOTICE: _realloc: size 28: client stash (free heap 122064)
[2017/12/06 01:58:45:0283] NOTICE: _realloc: size 33: strdup (free heap 122027)
[2017/12/06 01:58:45:0360] NOTICE: _realloc: size 69: strdup (free heap 121955)
[2017/12/06 01:58:45:0439] NOTICE: _realloc: size 33: strdup (free heap 121915)
[2017/12/06 01:58:45:0519] NOTICE: _realloc: size 33: strdup (free heap 121875)
[2017/12/06 01:58:45:0598] NOTICE: _realloc: size 16: strdup (free heap 121852)
[2017/12/06 01:58:45:0680] NOTICE: _realloc: size 4: strdup (free heap 121844)
[2017/12/06 01:58:45:0756] NOTICE: _realloc: size 996: ah struct (free heap 120848)
[2017/12/06 01:58:45:0839] NOTICE: _realloc: size 1024: ah data (free heap 119820)
[2017/12/06 01:58:45:0924] NOTICE: lws_client_connect_2: 0x3ffdf9b0: address acme-staging.api.letsencrypt.org
[2017/12/06 01:58:45:2018] NOTICE:  heap :119540 (-1908)
[2017/12/06 01:58:45:2198] NOTICE: lws_client_connect_2: 0x3ffdf9b0: address acme-staging.api.letsencrypt.org
tcp_connect: can only connect from state CLOSED
ssl_pm_handshake
[2017/12/06 01:58:45:2283] NOTICE: mbedtls_handshake: ssl ret 0 state 1
[2017/12/06 01:58:45:2368] NOTICE: mbedtls_handshake: ssl ret 0 state 2
[2017/12/06 01:58:45:2409] NOTICE: mbedtls_handshake: ssl ret -26880 state 2
ssl_pm_handshake
[2017/12/06 01:58:45:2620] NOTICE: mbedtls_handshake: ssl ret 0 state 3
[2017/12/06 01:58:45:2652] NOTICE: mbedtls_handshake: ssl ret -26880 state 3
ssl_pm_handshake
[2017/12/06 01:58:45:2782] NOTICE: mbedtls_handshake: ssl ret 0 state 4
[2017/12/06 01:58:45:2798] NOTICE: mbedtls_handshake: ssl ret -26880 state 4
ssl_pm_handshake
[2017/12/06 01:58:45:4393] NOTICE: mbedtls_handshake: ssl ret 0 state 5
[2017/12/06 01:58:45:4407] NOTICE: mbedtls_handshake: ssl ret 0 state 6
[2017/12/06 01:58:45:4433] NOTICE: mbedtls_handshake: ssl ret 0 state 7
[2017/12/06 01:58:45:4506] NOTICE: mbedtls_handshake: ssl ret 0 state 8
[2017/12/06 01:58:46:4011] NOTICE: mbedtls_handshake: ssl ret 0 state 9
[2017/12/06 01:58:46:4121] NOTICE: mbedtls_handshake: ssl ret 0 state 10
[2017/12/06 01:58:46:4153] NOTICE: mbedtls_handshake: ssl ret 0 state 11
[2017/12/06 01:58:46:4218] NOTICE: mbedtls_handshake: ssl ret 0 state 12
[2017/12/06 01:58:46:4247] NOTICE: mbedtls_handshake: ssl ret -26880 state 17
[2017/12/06 01:58:46:4321] NOTICE:  heap :89888 (-29652)
ssl_pm_handshake
[2017/12/06 01:58:46:4397] NOTICE: mbedtls_handshake: ssl ret 0 state 12
[2017/12/06 01:58:46:4475] NOTICE: mbedtls_handshake: ssl ret 0 state 13
[2017/12/06 01:58:46:4566] NOTICE: mbedtls_handshake: ssl ret 0 state 14
[2017/12/06 01:58:46:4607] NOTICE: mbedtls_handshake: ssl ret 0 state 15
[2017/12/06 01:58:46:4685] NOTICE: mbedtls_handshake: ssl ret 0 state 16
[2017/12/06 01:58:47:0048] NOTICE:  heap :94076 (+4188)
[2017/12/06 01:58:47:0232] NOTICE: lws_client_interpret_server_handshake: incoming content length 566
[2017/12/06 01:58:47:0240] NOTICE: lws_http_client_http_response 202
[2017/12/06 01:58:47:0297] NOTICE: lws_client_interpret_server_handshake: client connection up
[2017/12/06 01:58:47:0393] NOTICE: callback_acme_client: LWS_CALLBACK_RECEIVE_CLIENT_HTTP
{
  "type": "tls-sni-01",
  "status": "valid",
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/YhgQQM_BpfWU2Tl9jb8QTb7saGyXscUMVLy5e_AQRKM/81227871",
  "token": "oarSukJnEqj_IlV6smbV5xy5aTfrNMQis9Oc8_wDWLM",
  "keyAuthorization": "oarSukJnEqj_IlV6smbV5xy5aTfrNMQis9Oc8_wDWLM.h0e4fuUEPROpatCFyvIFz0zPz4qGJkGwgwSQI8ND8Ww",
  "validationRecord": [
    {
      "hostname": "home.warmcat.com",
      "port": "443",
      "addressesResolved": [
        "1.163.180.168"
      ],
      "addressUsed": "1.163.180.168",
      "addressesTried": []
    }
  ]
}

So I am looking forward to the update on the non-staging server. Thanks again.

2 Likes

Hi again @warmcat, (Have I mentioned I love your nick?)

That’s definitely a common source of confusion :slight_smile:

Excellent! I’m glad to hear the timeout increase was sufficient in combination with your connection queuing.

That should roll out on Thursday. The Boulder update and a changelog of commits is always posted to our status page. Production is only running one Validation Authority right now so it should be easier for your devices than the staging environment and its 3 extra validation connections.

Thanks again for the detailed issue, take care!

Thanks a lot guys… FYI it’s working already on the main server even without the timeout fix, but only because that currently only checks one time. The timeout increase there will allow it to continue to work if / when the checks are more robust there.

I pushed the update to git here https://github.com/warmcat/lws-esp32-factory

1 Like

Happy to help! Nice GUI :slight_smile: looks slick!

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