The TLS check runs only on an address whose port 443 the last port check found open, and the certificate cleanup removed an entry only when its name stopped resolving to the address. A certificate entry therefore stayed ok, with its old CN, issuer and expiry, for as long as its port was closed, on the dashboard and in /api/v1/status.
The cleanup that runs after the port checks (cleanupStaleCertificates) now also removes the certificate entries of an address whose port 443 was found closed. It sends nothing: the Port Change notification already reports the closed port. When the port opens again, the next TLS check saves the certificate as a new entry, with no change or recovery notification, as the decision comment on the issue says.
The README's TLS Certificate Monitoring and State Management sections say what happens to a certificate entry when its port closes. The "connection refused" case under TLS connection failure now says when it can still happen: the port closed after the port check that found it open. That window is wider than the issue assumed, since the checks on the TLS interval use the port state of the last port check, up to DNSWATCHER_DNS_INTERVAL old.
Judgement call: the entry is removed even while none of the name's nameservers answer, since the port check reached the address itself; keeping entries while no nameserver answers still applies to an address the name no longer resolves to.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/dnswatcher/issues/265.
The TLS check runs only on an address whose port 443 the last port check found open, and the certificate cleanup removed an entry only when its name stopped resolving to the address. A certificate entry therefore stayed `ok`, with its old CN, issuer and expiry, for as long as its port was closed, on the dashboard and in `/api/v1/status`.
The cleanup that runs after the port checks (`cleanupStaleCertificates`) now also removes the certificate entries of an address whose port 443 was found closed. It sends nothing: the Port Change notification already reports the closed port. When the port opens again, the next TLS check saves the certificate as a new entry, with no change or recovery notification, as the decision comment on the issue says.
The README's TLS Certificate Monitoring and State Management sections say what happens to a certificate entry when its port closes. The "connection refused" case under TLS connection failure now says when it can still happen: the port closed after the port check that found it open. That window is wider than the issue assumed, since the checks on the TLS interval use the port state of the last port check, up to `DNSWATCHER_DNS_INTERVAL` old.
Judgement call: the entry is removed even while none of the name's nameservers answer, since the port check reached the address itself; keeping entries while no nameserver answers still applies to an address the name no longer resolves to.
Model: opus-5-5
The TLS check runs only on an open port 443, and the certificate
cleanup removed an entry only when its name stopped resolving to the
address, so an entry stayed ok for as long as its port was closed.
The cleanup after the port checks now also removes the entries of an
address whose port 443 was found closed. Nothing is notified for the
removal; the Port Change already says the port closed. When the port
opens again, the next TLS check saves the certificate as new, with no
change or recovery notification. The README says both.
Judgement call: the entry goes even while none of the name's
nameservers answer, since the port check reached the address itself.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #265.
The TLS check runs only on an address whose port 443 the last port check found open, and the certificate cleanup removed an entry only when its name stopped resolving to the address. A certificate entry therefore stayed
ok, with its old CN, issuer and expiry, for as long as its port was closed, on the dashboard and in/api/v1/status.The cleanup that runs after the port checks (
cleanupStaleCertificates) now also removes the certificate entries of an address whose port 443 was found closed. It sends nothing: the Port Change notification already reports the closed port. When the port opens again, the next TLS check saves the certificate as a new entry, with no change or recovery notification, as the decision comment on the issue says.The README's TLS Certificate Monitoring and State Management sections say what happens to a certificate entry when its port closes. The "connection refused" case under TLS connection failure now says when it can still happen: the port closed after the port check that found it open. That window is wider than the issue assumed, since the checks on the TLS interval use the port state of the last port check, up to
DNSWATCHER_DNS_INTERVALold.Judgement call: the entry is removed even while none of the name's nameservers answer, since the port check reached the address itself; keeping entries while no nameserver answers still applies to an address the name no longer resolves to.
Model: opus-5-5
Review: PASS
Model: opus-5-5