When I try to visit a website that hasn't configured https correctly, this message pops up in Safari.


I appreciate the warning—it lets me know not to enter any personal information on the website. However, if the site is e.g. a standard blog, I still want to read it. So I click "Show Details" and then "visit this website".

This causes Safari to ask for my admin password, in order to make "changes to [my] Certificate Trust Settings". I don't want to make any lasting changes to my system, just read one website! Am I somehow making my computer permanently less secure, and if not, why does Safari need my admin password?

enter image description here

What is actually happening behind the scenes when I update my Certificate Trust settings in order to view one of these sites?

  • 2
    Just a tip, opening the same website in private mode can circumvent this prompt and gives a warning only. – anki Oct 13 '19 at 23:09

When you enter your password and press Update Settings, what really happens is that the certificate presented by that web site is added to the Certificates set in your login keychain. Your password is needed in order for Safari to have permission to add something to your keychain.

If you open up Keychain Access.app, select the login keychain and then the Certificates category, you'll find the specific certificate in the list on the right. The certificate is marked with a blue circle with a white plus inside it. This means it is marked as "trusted".

I.e. you're essentially overriding standard system behavior and stating that you trust a specific certificate even though it is not otherwise trusted (for example because it is expired). This is what will allow you to browse the site without further warnings.

Does it make your computer permanently less secure? - In some ways yes, because you're now trusting a certificate that is not really valid. If some malicious person used that certifcate to trick you then the system will trust that certificate. As you're manually stating that you do indeed trust the certificate, you're already aware that something is out of the ordinary, so it's not a huge problem. You just need to be aware that the trust doesn't automatically "expire" and disappear the next day or something like that.

If you want to manually revoke your trust, you can use Keychain Access.app to right-click on the certificate to Delete it. If you visit the same web site again with Safari, you'll get the warning again.

Note that some browsers (including Safari in Incognito Mode) solve the problem with overriding invalid certificates by allowing the user to override the warning temporarily. In that case nothing is added to the keychain, thus you do not need to enter a password. You can then browse the web site, but after you have closed down your browser, you'll get warnings again the next time you visit the site.

Also note that in these cases, you're only overriding the warning for that specific browser session. I.e. if you're using some other application (i.e. not the browser) to communicate with the site, such as a temporary override won't work. In contrast, doing what Safari does means that other programs (using the system trust store) will also respect your trust in that site.

  • Any comments on private mode's circumvention of the certificate editing? – anki Jan 14 '20 at 12:44
  • @ankii It simply does as I described in the last part of my answer. It's not really a "circumvention" at all. It's two different methods accomplishing two different things. – jksoegaard Jan 14 '20 at 13:22

When you allow Safari to "update settings", the certificate for that web site is added to a list of trusted certificates in your login keychain for web-based TLS (SSL) traffic, but the exception will be limited in scope since the certificate is not trusted for other uses, like S/MIME, code signing, IPsec encryption, etc.

In addition to using the Keychain Access app (as described by @jksoegaard), you can also view (and manipulate) "trusted certificates" from the shell using the security command.

security dump-trust-settings

will show certificates that have been trusted by the user, including those added when you click the "Visit this website" button in Safari. They will have a "Policy OID" of "SSL" and show the "Allowed Error", such as host name mismatch, expired certificate, etc.

In addition,

security dump-trust-settings -d

will show certificates that have been trusted by the administrator (added by a corporate MDM profile, for example). And

security dump-trust-settings -s

will show the certs trusted by macOS by default.

(Trusted certificates can be removed with security remove-trusted-cert and new ones added via security add-trusted-cert, but require the certificate in DER or PEM format. )

  • As far as I know, it's not really the case that it is added into the keychain for "web-based TLS (SSL) traffic", nor that "the certificate is not trusted for other uses". That's not really how things work. The certificate itself contains information about what it can be used for - when you visit ordinary certificates, they'll contain an "Extended Key Usage" section that tells that they can be used for "Server Authentication". This is why the certificate is trusted for web traffic (for example), but not for code signing. It's not a process of how the browser adds it to the keychain, but a [...] – jksoegaard Jan 20 '20 at 21:21
  • [...] property of the certificate itself. This doesn't mean that it is limited to be used only for "web-based TLS (SSL) traffic" - server authentication certificates can be used for other stuff. The browser cannot and does not restrict the trust of the certificate to be only web browsers. A certificate used for for example code signing, as you mention, would have an "Extended Key Usage" of "Code signing". However, there's absolutely nothing stopping you from trusting a certificate in this manner that has both server authentication and code signing usages. It would be weird and not issued [...] – jksoegaard Jan 20 '20 at 21:23
  • [...] by an ordinary CA... but as we're looking only at certificates that are not trusted by default, that's not really outstanding. – jksoegaard Jan 20 '20 at 21:24
  • I was just trying to point out that a certificate that gets added when you click "Update Settings" does not get set to "Always Trust". So even if did contain extended key usage fields, the certificate would not be trusted for that usage. Instead, the certificate gets set to a "Custom" level where only "Secure Soccer Layer (SSL)" is marked as "Always Trust". And even without any extended attributes, a certificate added this way could not (by default) be used for an IPSec VPN, for example. Reference – eddyg Jan 21 '20 at 12:15
  • Ah, yes that's right - if the certificate is indeed invalid, it can't be used by default for IPSec VPN for example. However, if the certificate is other valid, it can be used by default for IPSec VPN. I.e. when it is added to the Keychain, it is set to "Always trust" for SSL - but it is not set to "Never Trust" for other usages.. it just reverts to default. – jksoegaard Jan 21 '20 at 12:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .