For some reason (e.g., bad preferences setting, maybe?) Safari 6.0.5, on OS X 10.8.4, is failing to give me an SSL Certificate Warning when I visit a site whose hostname doesn't match the hostname bound to the site's certificate.

Reproduced below is the certificate information that Safari gave me, but only when I clicked on the "https" icon located between the favicon and the hostname (with domain name redacted). It plainly indicates that the certificate isn't valid for the hostname.

enter image description here

I believe that this information about the hostname mismatch should have appeared in a warning notifier containing the message:

Safari can't verify the identity of the website "sbxstg.redacted.com"

But I wasn't given any such notifier; just an address bar whose contents make it appear that everything went well and without error, and that I have a secure connection to the proper holder of the certificate. (!!)

Can someone please tell me where I should be looking to turn the warning feature back on, if I've somehow inadvertantly turned it off?

On the other hand, is it possible that I've found a corner-case/bug in Safari? Note that the domain to which Safari claims the certificate is bound is simply redacted.com, and not *.redacted.com. Could that possibly be confusing the algorithm that Safari uses to decide whether to pop up the warning?

For what it's worth, Firefox 21.0 running on the same Mac does give me the expected "This Connection is Untrusted" message, stating in the Technical Details section that:

sbxstg.redacted.com uses an invalid security certificate.

The certificate is only valid for the following names:

redacted.com , www.redacted.com."

Update: I've been able to reproduce this behavior on Safari 6.2.3, but only after getting an initial notifier warning me that there was a problem with the certificate ("Safari can't verify the identity of the website sbxstg.redacted.com. The certificate for this website is invalid...").

Once I'd clicked "Continue", though, subsequent attempts to load https://sbxstg.redacted.com appeared to work as described in my original post (i.e., no obvious, modal warning -- just the one that is hidden until displaying the certificate information).

So it looks like you get one chance. And if you decide "damn the torpedoes," then it's on you forever after to remember that there's something hinky about the site/cert, because you have effectively "turned off" the in-your-face warning for that particular site. (I theorize that when I originally posted this question, I must have already hit "Continue" at some earlier point, and didn't remember that I'd done so.)

So the question remains: How do I turn the warning feature back on?

2 Answers 2


So, as noted in the update, Safari does actually warn you -- once.

If you decide to proceed anyway, then for the remainder of that browser session, you need to remember that you're talking to a potentially compromised server, because you will see no evidence of that except by examining the certificate (by clicking on the https/padlock icon).

However, exiting Safari and restarting it restores the warning. A visit to the compromised site in the new instance of the browser once again presents the warning.


The Server could be having Subject Alternative Name.

You can verify the same by running the following command in Terminal.app

$ echo "" | openssl s_client -connect www.youtube.com:443 | openssl x509 -text |grep -i -A 5 'X509v3 Subject Alternative Name'

  • 1
    If there is a SAN (and it matches the host), then the red text in the screenshot won't appear when examining the certificate. It'll show "This certificate is valid".
    – vcsjones
    Commented Dec 5, 2013 at 15:27
  • The server certificate does have SAN, but as the Firefox warning states, it's only configured for redacted.com and www.redacted.com, and not for sbxstg.redacted.com . I can also see the two valid DNS names in the Safari "Details" scroll for the cert on Safari 6.2.3. (I guess I might have also been able to see the same info on Safari 6.0.5, but didn't know it was available when I posted the question.)
    – Hephaestus
    Commented Mar 11, 2015 at 4:24
  • That said, a belated thanks to @Garfield Carneiro for mentioning Server Alternative Name (which I hadn't known about before then), even though it turned out not to be the cause of the issue.
    – Hephaestus
    Commented Mar 11, 2015 at 4:57

You must log in to answer this question.

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