• 1 Post
  • 22 Comments
Joined 7 months ago
cake
Cake day: June 7th, 2025

help-circle













  • There’s no natural signal back to the operators that the SSL certificate is getting close to expiry.

    Not sure what the author considers a natural signal, but it’s definitely possible to monitor time to expiry, for example with the Prometheus blackbox exporter.

    Furthermore, I have issues with calling SSL Certificates dangerous. The author cites a lack of graceful degradation (and suggests that site errors should increase as certs get closer to expiry???) and the fact that they cannot be staged because time is the variance… However, staging certs is possible. One does not need to wait until the previous cert expires before issuing a new one. In fact, the new cert doesn’t even need to be signed by the same CA. So it’s possible to generate a new cert, test it, and then have it go live. In fact, ACME does do this to a limited degree, and the article does mention that the automated cert renewal process failed and that such failure was not noticed due to missed monitoring signals. So the title should have been “Insufficient monitoring is dangerous.”

    Lastly to be pedantic: s/SSL/TLS/



  • On the other hand, people who don’t know enough about how WiFi bands work will look at the channels used in the area, see that they tend to “crowd” on channels at specific intervals (e.g. channels 1, 7, and 11 for 2.4GHz networks), and think they’re better off picking an in-between one because hey, it’s not used. However they don’t realize that by doing so they make everyone’s WiFi worse including their own, because those “crowded” channels are preferred so that they don’t overlap with each other. If everyone picks channels 1, 7, or 11 then they will only conflict with signals from those channels. Someone then picking e.g. channel 4 will conflict with everyone on channels 1 and 7.