Enabling Safari to successfully connect after changing a self-signed certificate

Every so often, I need to use Safari to access something which is using a self-signed certificate. When I do so, Safari now walks you through the following procedure:

1. Warns you something’s not right and give you the option of either going back or seeing the details.
2. If you choose to see the details, Safari will let you view the certificate.

Safari will also give you the option of proceeding anyway.

If you choose to proceed anyway, Safari will store the self-signed certificate in your login keychain and mark it as trusted.

With this certificate now marked as trusted, Safari will allow you to visit the website.

However, what happens when the SSL certificate changes but keeps the same subject name? At this point, connections from Safari to the site will fail with an error message similar to the one described below:

Safari Can’t Open the Page
Safari can’t open the page because Safari can’t establish a secure connection to the server “server.name.here”.

The reason that this message appears is because Safari is using HTTP Strict Transport Security, otherwise known as HSTS. One of the requirements of HSTS as implemented by Safari is that if the security of the connection cannot be ensured, Safari must terminate the connection and should not allow the user to access the web application.

Since the self-signed certificate stored in your login keychain and the SSL certificate being received don’t match each other, that tells Safari that the certificate being received can’t be trusted. The result is Safari immediately terminates the connection and displays an error message like the one shown above.

However, what if the certificate changing is known behavior and you know that proceeding is safe? It’s possible to re-set Safari’s behavior, but it’s not intuitive. For more details, please see below the jump.

Upgrading from ESXi 6.7 to ESXi 7.0 via SSH and esxcli

Following VMware’s release of ESXi 7.0, I upgraded my ESXi 6.7 server to ESXi 7.0 using SSH and esxcli. For those interested, see below the jump for the details of the process I used.

Erasing a FileVault-encrypted T2-equipped Mac

Normally, reinstalling macOS on a Mac is a straightforward process:

1. Boot to macOS Recovery
2. Select Reinstall macOS from macOS Utilities.

3. Follow the onscreen instructions.

However, if you have a Mac equipped with a T2 chip where FileVault is turned on, there’s an extra step involved. When you boot to macOS Recovery on a T2 Mac with FileVault on, you will be prompted for the password of an account on the Mac which has admin privileges.

If you don’t have the password to any of the accounts which appear, you can select the Forget all passwords? option.

This will bring up a new screen where you can enter a FileVault Personal Recovery Key.

If you can provide either the account password or the personal recovery key, the next thing you should see is the macOS Utilities screen.

 

What if you don’t have either a password or a personal recovery key? Is your Mac now a paperweight? For more details, please see below the jump.