Custom Query (196 matches)

Currently lockername.scripts.mit.edu gives a certificate error. We have a valid certificate for *.scripts.mit.edu but it is currently not used. The problem is that (modulo recent extensions) the HTTPS protocol doesn’t support sending the virtual host name before the server must decide which certificate to present.

There have been two proposed solutions. One is to use the ​SNI extension. This requires upgrading OpenSSL to at least 0.9.8f, ​patching mod_ssl, and using relatively recent browsers (old browsers will fall back to the current behavior).

The other is to move *.scripts.mit.edu to a separate IP from scripts.mit.edu, so that the server knows which certificate to present based on the IP. This is less general (we can’t extend this to work with arbitrary vhosts), but we could probably implement it now.

Currently, the directors check port 25 on each machine to see if postfix is running. This is bad, since it means we can't nolvs a machine and prevent it from also handling mail. Mitch wrote patches a few years ago that use the nagios ldap check and provide the smtp service that heartbeat can ping. This allows us to nolvs a machine and have it drop out of all services, meaning we can temporarily take a wedged machine out of the pool for debugging.

davidben points out that ​Chrome will be degrading SHA-1 certificates valid past 2016-01-01:

The following changes to Chromium's handling of SHA-1 are proposed:

• All SHA-1-using certificates that are valid AFTER 2017/1/1 are treated insecure, but without an interstitial. That is, they will receive a degraded UI indicator, but users will NOT be directed to click through an error page.
• Additionally, the mixed content blocker will be taught to treat these as mixed content, which WILL require a user action to interact with.
• All SHA-1-using certificates that are valid AFTER 2016/1/1 are treated as insecure, but without an interstitial. They will receive a degraded UI indicator, but will NOT be treated as mixed content.

This seems to include all certificates that mitcert/InCommon has issued (and continues to issue!) since 2013-01-01, since they have a three year expiration date.

So we’re going to need to replace all these certificates soon. This might also be a good excuse to move to a 2048-bit private key (because a 4096-bit certificate signed by 2048-bit CAs provides no security benefit and is noticeably slower).