V2: Why wasn't cert available after reload + restart, only after reboot?

1. My Caddy version (caddy -version):

v2.0.0-beta.14 h1:QX1hRMfTA5sel53o5SuON1ys50at6yuSAnPr56sLeK8=

2. How I run Caddy:

a. System environment:

Ubuntu 19.10 eoan (GNU/Linux 5.3.0-29-generic x86_64)
in a virtual server on Linode

c. Service/unit/compose file:

[Unit]
Description=Caddy v2 web server
Documentation=https://caddyserver.com/docs/
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
#Restart=on-abnormal

; Do not allow the process to be restarted in a tight loop. If the
; process fails to start, something critical needs to be fixed.
;StartLimitIntervalSec=14400
;StartLimitBurst=10

; User and group the process will run as.
User=www-data
Group=www-data

; caddy command assumes the caddyfile adapter if filename starts with Caddyfile
ExecStart=/usr/local/bin/caddy run --config /etc/caddy/Caddyfile
ExecReload=/usr/local/bin/caddy reload --config /etc/caddy/Caddyfile

; Use graceful shutdown with a reasonable timeout
ExecStop=/usr/local/bin/caddy stop
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s

; Limit the number of file descriptors; see `man systemd.exec` for more limit settings.
LimitNOFILE=1048576
; Unmodified caddy is not expected to use more than that.
LimitNPROC=4096

; The following additional security directives only work with systemd v229 or later.
; They further restrict privileges that can be gained by caddy. Uncomment if you like.
; Note that you may have to add capabilities required by any plugins in use.
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile:

# global options block
{
	storage file_system {
		root	/etc/caddy/storage
	}
	experimental_http3
	email 	skyfaller@gmail.com
}

# reusable snippets
(boilerplate) {
	encode gzip zstd
	file_server
}

# start site blocks

# test page
www.sunrisemovement.dev {
	root * /srv/sunrisemovement.dev/public/
#	try_files {path}.html {path}
	import boilerplate
}

# redirect no-www to www
sunrisemovement.dev {
	redir https://www.sunrisemovement.dev
}

# handcoded Rhode Island site
ri.sunrisemovement.dev {
	root * /srv/sunrisemovement.dev/ri/public
#	try_files {path}/ {path} {path}.php
	import boilerplate
	php_fastcgi unix//var/run/php/php7.3-fpm.sock
}

# handcoded SF Bay website (originally Github Pages)
sfbay.sunrisemovement.dev {
	root * /srv/sunrisemovement.dev/sfbay/public
	import boilerplate
}
sfbay.sunrisemovement.org {
	root * /srv/sunrisemovement.org/sfbay/public
	import boilerplate
}

3. The problem I’m having:

I added the website sfbay.sunrisemovement.org to my Caddyfile, then reloaded Caddy. The website wouldn’t load, and returned an SSL error. Seemed it wasn’t able to get the cert for some reason. So I restarted Caddy. Caddy got the cert, according to the log. But it still behaved as if it didn’t have the cert and refused to serve the website, despite having just fetched the cert!

EDIT: OK, now I see that the cert wasn’t actually fetched after restarting Caddy, it only said “The server validated our request”. We only got the message “Server responded with a certificate” after rebooting the virtual server. My question as to why this happened remains.

So I rebooted my virtual server, and because computers are voodoo magic everything worked fine once the server came back up. Why wasn’t restarting Caddy good enough?? I figured I’d post here anyway, just in case this info is useful to someone, maybe even my future self.

4. Error messages and/or full log output:

Here’s the output of journalctl --boot -u caddy.service after restart:

Feb 14 09:00:16 attenborough systemd[1]: Started Caddy v2 web server.
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.581        INFO        using provided configuration        {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.591        INFO        admin        admin endpoint started        {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.592        INFO        http        server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS        {"server_name": "srv0", "https_port": 443}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.592        INFO        http        enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.594        INFO        http        enabling experimental HTTP/3 listener        {"addr": ":443"}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.595        INFO        http        enabling automatic TLS certificate management        {"domains": ["sfbay.sunrisemovement.org", "www.sunrisemovement.dev", "ri.sunrisemovement.dev", "sunrisemovement.dev", "sfbay.sunrisemovement.dev"]}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 09:00:16 [INFO][cache:0xc00071fdb0] Started certificate maintenance routine
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.628        INFO        tls        cleaned up storage units
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.629        INFO        autosaved config        {"file": "/var/www/.config/caddy/autosave.json"}
Feb 14 09:00:16 attenborough caddy[24906]: 2020/02/14 14:00:16.629        INFO        serving initial configuration
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO][sfbay.sunrisemovement.org] Obtain certificate
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO][sfbay.sunrisemovement.org] Obtain: Waiting on rate limiter...
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO][sfbay.sunrisemovement.org] Obtain: Done waiting
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO] [sfbay.sunrisemovement.org] acme: Obtaining bundled SAN certificate
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO] [sfbay.sunrisemovement.org] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2814213773
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO] [sfbay.sunrisemovement.org] acme: Could not find solver for: tls-alpn-01
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO] [sfbay.sunrisemovement.org] acme: use http-01 solver
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO] [sfbay.sunrisemovement.org] acme: Trying to solve HTTP-01
Feb 14 09:00:18 attenborough caddy[24906]: 2020/02/14 09:00:18 [INFO][sfbay.sunrisemovement.org] Served key authentication (HTTP challenge)
Feb 14 09:00:19 attenborough caddy[24906]: 2020/02/14 09:00:19 [INFO][sfbay.sunrisemovement.org] Served key authentication (HTTP challenge)
Feb 14 09:00:19 attenborough caddy[24906]: 2020/02/14 09:00:19 [INFO][sfbay.sunrisemovement.org] Served key authentication (HTTP challenge)
Feb 14 09:00:19 attenborough caddy[24906]: 2020/02/14 09:00:19 [INFO][sfbay.sunrisemovement.org] Served key authentication (HTTP challenge)
Feb 14 09:00:22 attenborough caddy[24906]: 2020/02/14 09:00:22 [INFO] [sfbay.sunrisemovement.org] The server validated our request
Feb 14 09:00:39 attenborough caddy[24906]: 2020/02/14 09:00:39 http: TLS handshake error from [2601:42:0:6200:34b6:1a6f:6149:7b56]:49548: no certificate available for 'sfbay.sunrisemovement.org'
Feb 14 09:00:42 attenborough caddy[24906]: 2020/02/14 09:00:42 http: TLS handshake error from [2601:42:0:6200:34b6:1a6f:6149:7b56]:49552: no certificate available for 'sfbay.sunrisemovement.org'

after I rebooted the virtual server:

-- Logs begin at Sun 2020-01-26 02:12:23 EST, end at Fri 2020-02-14 09:45:58 EST. --
Feb 14 09:27:51 attenborough systemd[1]: Started Caddy v2 web server.
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.720        INFO        using provided configuration        {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.744        INFO        admin        admin endpoint started        {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.745        INFO        http        server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS        {"server_name": "srv0", "https_port": 443}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.750        INFO        http        enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.754        INFO        http        enabling experimental HTTP/3 listener        {"addr": ":443"}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.758        INFO        http        enabling automatic TLS certificate management        {"domains": ["sfbay.sunrisemovement.dev", "sfbay.sunrisemovement.org", "www.sunrisemovement.dev", "ri.sunrisemovement.dev", "sunrisemovement.dev"]}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 09:27:51 [INFO][cache:0xc0002b05f0] Started certificate maintenance routine
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.863        INFO        tls        cleaned up storage units
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.867        INFO        autosaved config        {"file": "/var/www/.config/caddy/autosave.json"}
Feb 14 09:27:51 attenborough caddy[651]: 2020/02/14 14:27:51.867        INFO        serving initial configuration
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO][sfbay.sunrisemovement.org] Obtain certificate
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO][sfbay.sunrisemovement.org] Obtain: Waiting on rate limiter...
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO][sfbay.sunrisemovement.org] Obtain: Done waiting
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO] [sfbay.sunrisemovement.org] acme: Obtaining bundled SAN certificate
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO] [sfbay.sunrisemovement.org] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2814213773
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO] [sfbay.sunrisemovement.org] acme: authorization already valid; skipping challenge
Feb 14 09:27:52 attenborough caddy[651]: 2020/02/14 09:27:52 [INFO] [sfbay.sunrisemovement.org] acme: Validations succeeded; requesting certificates
Feb 14 09:27:53 attenborough caddy[651]: 2020/02/14 09:27:53 [INFO] [sfbay.sunrisemovement.org] Server responded with a certificate.

5. What I already tried:

Rebooting virtual server, and annoyingly that worked.

Now that you have published your domain name, I have checked the status of the certificate:
https://crt.sh/?q=sfbay.sunrisemovement.org

It is issued today as well. Why is it issued weekly until February 10?
That could be the cause.

@balloon that’s a really good question, thank you for this resource. I was not previously hosting this subdomain, I grabbed control of it in our domain registrar (GoDaddy) last night and pointed it to my server (running Caddy). I have to assume the previous person hosting this subdomain was doing something strange.

EDIT: Actually, could you explain why issuing the certificate weekly is weird or bad? I know Let’s Encrypt generally favors shorter certificate lifetimes, and weekly certs seems like taking that philosophy to its logical conclusion.

Has the IP address of the subdomain sfbay.sunrisemovement.org just changed?
If it is correct, the name server has a cache (TTL), so you need to wait.
Launch Caddy again after a few hours to a few days.

@balloon Yes, the IP address changed. But our default TTL in Godaddy is 1 hour, which is why I changed where the subdomain was pointed last night and tried activating it in Caddy this morning. I waited much more than an hour. Besides, I don’t think that fully explains why the restart didn’t work but the reboot did… I doubt that it was a matter of waiting one more minute for my Linode to reboot.

I still don’t really know what happened here but some changes I’m working on in CertMagic right now improve logging and also fix a bug where a cert that is renewed right at startup wouldn’t be applied in memory right away. So, maybe upgrade in a couple weeks and see if this happens again.

(Edit, a couple weeks later: this work isn’t finished yet, so check back in a couple weeks :sweat_smile: )

1 Like

It happened again, with the latest dev version compiled from source commit e6c6210.

I was trying to get a new domain working last night, but I had to wait on the TTL for my DNS before Let’s Encrypt would cooperate. So I powered off the server and went to bed. Today, when I woke up I turned on the server and saw this happen:

-- Reboot --
Mar 03 11:52:20 wiley systemd[1]: Started Caddy v2 web server.
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.312        INFO        using provided configuration        {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.318        INFO        admin        admin endpoint started        {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.319        INFO        http        server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS        {"server_name": "srv0", "https_port": 443}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.319        INFO        http        enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.319        INFO        http        enabling experimental HTTP/3 listener        {"addr": ":443"}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.320        INFO        http        enabling automatic TLS certificate management        {"domains": ["test.sunrisepvd.com"]}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.322        INFO        tls        cleaned up storage units
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.323        INFO        autosaved config        {"file": "/var/www/.config/caddy/autosave.json"}
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 16:52:21.323        INFO        serving initial configuration
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 11:52:21 [INFO][cache:0xc0005f6e10] Started certificate maintenance routine
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 11:52:21 [INFO][test.sunrisepvd.com] Obtain certificate
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 11:52:21 [INFO][test.sunrisepvd.com] Obtain: Waiting on rate limiter...
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 11:52:21 [INFO][test.sunrisepvd.com] Obtain: Done waiting
Mar 03 11:52:21 wiley caddy[970]: 2020/03/03 11:52:21 [INFO] [test.sunrisepvd.com] acme: Obtaining bundled SAN certificate
Mar 03 11:52:22 wiley caddy[970]: 2020/03/03 11:52:22 [INFO] [test.sunrisepvd.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3133256865
Mar 03 11:52:22 wiley caddy[970]: 2020/03/03 11:52:22 [INFO] [test.sunrisepvd.com] acme: Could not find solver for: tls-alpn-01
Mar 03 11:52:22 wiley caddy[970]: 2020/03/03 11:52:22 [INFO] [test.sunrisepvd.com] acme: use http-01 solver
Mar 03 11:52:22 wiley caddy[970]: 2020/03/03 11:52:22 [INFO] [test.sunrisepvd.com] acme: Trying to solve HTTP-01
Mar 03 11:52:23 wiley caddy[970]: 2020/03/03 11:52:23 [INFO][test.sunrisepvd.com] Served key authentication (HTTP challenge)
Mar 03 11:52:23 wiley caddy[970]: 2020/03/03 11:52:23 [INFO][test.sunrisepvd.com] Served key authentication (HTTP challenge)
Mar 03 11:52:23 wiley caddy[970]: 2020/03/03 11:52:23 [INFO][test.sunrisepvd.com] Served key authentication (HTTP challenge)
Mar 03 11:52:23 wiley caddy[970]: 2020/03/03 11:52:23 [INFO][test.sunrisepvd.com] Served key authentication (HTTP challenge)
Mar 03 11:52:26 wiley caddy[970]: 2020/03/03 11:52:26 [INFO] [test.sunrisepvd.com] The server validated our request
Mar 03 11:53:17 wiley caddy[970]: 2020/03/03 11:53:17 http: TLS handshake error from [2601:42:0:6200:c163:2831:174e:3727]:52017: no certificate available for 'test.sunrisepvd.com'
Mar 03 11:53:18 wiley caddy[970]: 2020/03/03 11:53:18 http: TLS handshake error from 167.71.121.170:50712: no certificate available for 'test.sunrisepvd.com'
Mar 03 11:53:18 wiley caddy[970]: 2020/03/03 11:53:18 http: TLS handshake error from 167.71.121.170:50772: no certificate available for 'test.sunrisepvd.com'

Why is the server validating our request, but not delivering a certificate? I bet if I reboot one or more times, this problem will solve itself like last time, but I’d like to track down what’s causing this issue anyway.

After waiting a little to see if it would resolve itself, I got bored and restarted the Caddy service with a sudo systemctl restart caddy. Sure enough, restarting Caddy fixed the problem, the certificate was fetched as expected, everything works fine now.

Mar 03 12:38:43 wiley caddy[970]: 2020/03/03 12:38:43 http: TLS handshake error from [2601:42:0:6200:c163:2831:174e:3727]:52359: no certificate available for 'test.sunrisepvd.com'
Mar 03 12:39:57 wiley systemd[1]: Stopping Caddy v2 web server...
Mar 03 12:39:58 wiley caddy[970]: 2020/03/03 17:39:58.013        INFO        admin.api        received request        {"method": "POST", "uri": "/stop", "remote_addr": "127.0.0.1:42400", "headers": {"Accept-Encoding":["gzip"],"Content-Length":["0"],"Origin":["localhost:2019"],"User-Agent":["Go-http-client/1.1"]}}
Mar 03 12:39:58 wiley caddy[970]: 2020/03/03 17:39:58.014        INFO        admin.api        unloading
Mar 03 12:39:58 wiley caddy[970]: 2020/03/03 12:39:58 [DEBUG] Fake-closing underlying packet conn
Mar 03 12:39:58 wiley caddy[970]: 2020/03/03 12:39:58 [INFO][cache:0xc0005f6e10] Stopped certificate maintenance routine
Mar 03 12:39:58 wiley caddy[970]: 2020/03/03 17:39:58.014        INFO        admin.api        unloading completed
Mar 03 12:39:58 wiley caddy[970]: 2020/03/03 17:39:58.017        INFO        quitting process immediately        {"signal": "SIGQUIT"}
Mar 03 12:39:58 wiley systemd[1]: caddy.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Mar 03 12:39:58 wiley systemd[1]: caddy.service: Failed with result 'exit-code'.
Mar 03 12:39:58 wiley systemd[1]: Stopped Caddy v2 web server.
Mar 03 12:39:58 wiley systemd[1]: Started Caddy v2 web server.
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.055        INFO        using provided configuration        {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.058        INFO        admin        admin endpoint started        {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.059        INFO        http        server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS        {"server_name": "srv0", "https_port": 443}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.059        INFO        http        enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.060        INFO        http        enabling experimental HTTP/3 listener        {"addr": ":443"}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.060        INFO        http        enabling automatic TLS certificate management        {"domains": ["test.sunrisepvd.com"]}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.060        INFO        tls        cleaned up storage units
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.078        INFO        autosaved config        {"file": "/var/www/.config/caddy/autosave.json"}
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 17:39:58.078        INFO        serving initial configuration
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO][cache:0xc0005f8e10] Started certificate maintenance routine
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO][test.sunrisepvd.com] Obtain certificate
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO][test.sunrisepvd.com] Obtain: Waiting on rate limiter...
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO][test.sunrisepvd.com] Obtain: Done waiting
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO] [test.sunrisepvd.com] acme: Obtaining bundled SAN certificate
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO] [test.sunrisepvd.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3133256865
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO] [test.sunrisepvd.com] acme: authorization already valid; skipping challenge
Mar 03 12:39:58 wiley caddy[1503]: 2020/03/03 12:39:58 [INFO] [test.sunrisepvd.com] acme: Validations succeeded; requesting certificates
Mar 03 12:39:59 wiley caddy[1503]: 2020/03/03 12:39:59 [INFO] [test.sunrisepvd.com] Server responded with a certificate.

Do you think this could be similar to Https certificate hang ?

1 Like

Upon inspection, I’m pretty sure it’s either a bug in lego or its dependency (a backoff library). (Links in other thread.) Bug filed upstream: https://github.com/go-acme/lego/issues/1075

1 Like

@skyfaller Would you be able to upgrade to the latest on the v2 branch (newer than beta 18, will go out with beta 19)? I think I’ve fixed a bug today that was at least related to the hanging, if not the hanging itself. Did you notice that this only happens with the HTTP challenge? If so, it might very well have been fixed now… if not, meh, we’ll see. Let me know after you upgrade if it happens or doesn’t happen again!

After 20 trials I was unable to replicate the issue (which I have experienced before myself since your report).

1 Like