[bobbob1921]

I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext, yet plaintext has to get used because of some element of certificates expiring needs renwal. Even bad or easy to crack encryption is better than plain text, yet I totally get why many scenarios end up using plain text (i’m talking in an internal or home lab type set up). I understand why public facing certificates need renewals

[weddpros]

You could see expiring certificates as a chance to examine your security regularly: protocols and ciphers change, bugs are fixed, vulnerabilities are discovered and fixed.

Setup and forget is never good for security. From what I see with sslboard.com (I'm the founder), all hosts serving old expired certificates also have bad TLS versions and ciphers (RC4, DES) and vulnerabilities.

[cortesoft]

> I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext

Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.

[8organicbits]

Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate.

This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is needed.

I wrote much more here: https://alexsci.com/blog/is-email-confidential-in-transit-ye...

[teraflop]

For an internal use case, nothing's stopping you from setting up your own CA, creating certificates that don't expire for 100 years, and telling your clients to trust them. It just takes a couple of OpenSSL commands which, while slightly complicated if you don't know what you're doing, can be easily automated with a shell script.

The browser limits on maximum certificate lifetimes only apply to the public web PKI, not to CAs that you configure yourself.

[dns_snek]

You don't even need to remember any OpenSSL commands. I manage all of my home certificates using XCA GUI.

When creating your CA certificate you can hop into the Advanced tab and add the following line to constrain it to specific domains. This eliminates the risk of your likely-poorly-secured CA being abused to MITM all of your communications:

        nameConstraints=critical,permitted;DNS:.home.internal

This will only allow CA to sign certificates for *.home.internal. I think browser support for nameConstraints is pretty good these days but some clients might not be compatible and you can always install a CA certificate without this extension on devices that don't support it.

[op00to]

Modern web browsers have started distrusting certificates over a certain lifetime. So annoying!