Hi,

If Safari gives you a warning, you should have the option to look at the 
certificate and then continue. Do take the time to understand why the warning 
was raised in the first place before clicking on. 

If you are asking about how to add approved CAs to Safari, you do this via the 
keychain. What you need is the root CA certificate from the CA or organization 
that generated the certificate. This is somewhat common in the corporate world 
for corporate managed services. If you are curious as to the exact details, 
here is a page I had bookmarked on the topic. 
http://www.techrepublic.com/blog/apple-in-the-enterprise/managing-ssl-certificate-authorities-on-os-x/

That said, it's not something I would generally recommend for the non corporate 
user or some other special circumstance.

Best,
--k
Faith doesn't give you the answers, it merely stops you from asking the 
questions.


On Jul 6, 2014, at 9:24 PM, Jessica D <jldai...@gmail.com> wrote:

> So how do we add this to safaris list of trusted certificates?
> 
> Sent from my iPhone
> 
>> On Jul 6, 2014, at 11:20 AM, Kayaker <sea...@me.com> wrote:
>> 
>> Hi,
>> 
>> Certificates are not as intuitive as they should be. If you get a 
>> certificate warning from a web site, it doesn't mean it is an invalid 
>> certificate. I will attempt to simplify what is happening at the cost of 
>> some technical accuracy, but I think this will help you all understand what 
>> is going on.
>> 
>> The HTTPS is basically HTTP over what is called SSL/TLS. This tries to 
>> protect against two things: first, ensuring the site you are connecting to 
>> is in fact the site you expect and second providing a secure encrypted 
>> connection for data between you and the server.  This oversimplification of 
>> how this works is by having a server you connect to send you a certificate. 
>> This certificate contains a lot of information. It contains information 
>> about the domain, the date the certificate was issued, how long the 
>> certificate is valid for, and most important, the public key for the server. 
>> It also includes information about who issued the certificate. Certificates 
>> are usually issued by a Certificate Authority or CA. A CA is a trusted 
>> company like Verisign and your web browser has a list of valid CA companies 
>> it recognizes. When you first connect to a server via HTTPS, your browser 
>> tries to validate the certificate with the CA. If your browser doesn't 
>> recognize your CA as a trusted one, it will warn you. It doesn't mean the CA 
>> is bad, or the certificate is bad, it means the browser doesn't know the 
>> validity of the CA. It is perfectly valid to generate your own certificate 
>> and public and private keys without using a CA. One would do this because 
>> one cares more about encryption than validating the site as the one your are 
>> trying to connect to. If you remotely connect to your Mac with ssh, you have 
>> sort of done this with your own self signed certificate. 
>> 
>> Now a bank wants a certificate that can validate who it is. They will pay a 
>> big deal of cash to have a CA issue them a certificate. The CA validates the 
>> request by looking up business address, calling the main phone number, and 
>> some other basic private investigation work. This prevents some hacker in 
>> eastern Europe from obtaining a valid certificate from a CA. This is good if 
>> you are a bank.
>> 
>> The take away is that some certificates are more trusted than others. I want 
>> to trust my bank a whole lot more than online mom and pop shop.
>> 
>> So, you need a certificate for HTTPS. Now, what errors can the browser give 
>> you and where are the holes. As I said, the first warning comes if the 
>> browser doesn't have the CA in it's trusted list of CAs. This varies from 
>> browser to browser. This is a warning because you might know more than the 
>> browser's developer. The second error is if the CA rejects the validity of 
>> the certificate, like the fingerprints don't match. Another error can be the 
>> certificate has expired. Apple actually made this mistake recently on the 
>> app store. 
>> 
>> Now, here is one huge hole in the process. Remember the heart bleed bug? 
>> Well, certificates also have a private key. This private key is the most 
>> important piece of secret data and is never given out publicly. The private 
>> key is needed to decrypt the data. If a bad guy gets the private key, this 
>> means that anyone could make a public key from the private and spoof a web 
>> site. So, Owners of a certificate can revoke a certificate if it thinks the 
>> private key has been compromised or for any other reason. No big deal right? 
>> Well, turns out it is. The mechanism for checking a revoked certificate is 
>> off by default in most all browsers. Google's chrome doesn't even really 
>> bother to check if a certificate has been revoked. Safari is not much better 
>> in checking. So until a certificate truly expires, a revoked certificate 
>> will often work without warning the user.
>> 
>> More than you wanted to know, probably, but knowing why your browser warns 
>> about a certificate is important so you can judge the validity of the risk. 
>> In the case of NFB, I'd worry a little less, looks like the CA is not 
>> trusted by the browser. However, since you went to the site yourself, 
>> validating that nfb is nfb is a little less important. It's when you click 
>> on that link from your email to your bank that it becomes critical. 
>> 
>> So, what do I do as best practice? If I get a warning like that, I look to 
>> see who issued the certificate. If it is self signed, and I went to site, I 
>> don't worry about it at all if it's a small shop or non profit.
>> 
>> Hope this helps a little and didn't confuse you all more.  Again, some 
>> details were left out for simplicity sake in the hopes to make this a bit 
>> less daunting.
>> 
>> Best,
>> --k
>> Faith doesn't give you the answers, it merely stops you from asking the 
>> questions.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jul 4, 2014, at 9:20 AM, Littlefield, Tyler <ty...@tysdomain.com> wrote:
>>> 
>>> You really shouldn't ignore that. It means that the certificate is invalid. 
>>> If this is something on the NFB side, they should really really renew it. 
>>> If you're paying for anything with a credit card, the last thing you want 
>>> is an insecure connection.
>>> 
>>> Sincerely,
>>> the Constantly sock-footed me, Still a very happy windows, mac and IPhone 
>>> user!
>>> Sent from my toaster (TM): the only toaster with full accessibility built 
>>> in without a vm!
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "MacVisionaries" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to macvisionaries+unsubscr...@googlegroups.com.
>>> To post to this group, send email to macvisionaries@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/macvisionaries.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "MacVisionaries" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to macvisionaries+unsubscr...@googlegroups.com.
>> To post to this group, send email to macvisionaries@googlegroups.com.
>> Visit this group at http://groups.google.com/group/macvisionaries.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "MacVisionaries" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to macvisionaries+unsubscr...@googlegroups.com.
> To post to this group, send email to macvisionaries@googlegroups.com.
> Visit this group at http://groups.google.com/group/macvisionaries.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To post to this group, send email to macvisionaries@googlegroups.com.
Visit this group at http://groups.google.com/group/macvisionaries.
For more options, visit https://groups.google.com/d/optout.

Reply via email to