In Keychain, I have two self-signed root certificates that “are not to be trusted”:
1) com.apple.kerberos.kdc
2) com.apple.systemdefault

Should these certificates be trashed or are they merely false positives? Alas, I no knot their provenance or whence they came.

I also have those (and also don't know what they are), except I have two of com.apple.systemdefault and they have different years for expiry - 2028 and 2029.

My information doesn't help you get to an answer but it does let you know you're not alone in your perplexity.

ryck

> "I have two of com.apple.systemdefault"

Take a look at their "Kind;" is one a "certificate" and the other a "public key," as is the case in my 10.6.8 installation? (Someone else will have to explain the difference between the two.)

My "certificate" "is not trusted," same as yours and Harv's, and I haven't got a "kerberos" item.

This is quite likely related to the issue discussed in Security Updates.

I did notice that I haven't got any DigiNotar certificates, but I don't know whether I ever had any.

com.apple.kerberos.kdc is a self-signed key used for Kerberos authentication when you log into another Mac in your local area network, log into Back To My Mac, log into iCloud or MobileMe, or use Apple screen sharing.

It is necessary for automatic negotiation and encryption of the username and password for these functions. It's not signed by a CA because it's not unique to a particular computer, which is why it's "not trusted". If you delete it, you will not be able to automatically log in to any of those services, even if you tell the system to remember your username and password in the Keychain.

I believe, though I'm not sure, that com.apple.systemdefault is used to automatically log you on to the computer if you have automatic login available. It also isn't signed by a CA because it's the generic encryption key that is used to protect your system password. Deleting this certificate could cause problems with logging on to your compute; I recommend leaving it alone.

Neither of these is related to the DigiNotar certificate revocation.

I've got a com.apple.systemdefault "public" key and a com.apple.systemdefault "private" key in addition to my com.apple.systemdefault "certificate."

To do the three differ? (Harv's original post referred to the certificate.)

There are two com.apple.systemdefault certificates which are the same (except for the expiry dates) and are described as "Self-signed root certificate".

There are two com.apple.systemdefault keys called public key and two com.apple.systemdefault keys called private key. I assume it's one of each to go with the two certificates of the same name.

ryck

Thanks for correcting my misconception.

A public key and a private key are different; they're related, though.

The most common form of encryption today is a type of encryption called "public key encryption." It solves the biggest problem of any kind of code or cipher: how to get the key to another person.

With conventional codes or ciphers, if I want to share an encrypted message with you, I have to give you the key. If it is difficult or dangerous for me to talk to you, which it presumably is or we wouldn't need encryption, then it is difficult for me to give you the key, because if the key is intercepted or falls into the wrong hands, then all our messages can be read. And I cant encrypt the key and then give it to you, because without knowing wha the key is, you can't decrypt it! In wartime, this is especially bad, because if you're in the field and you are captured, then the keys you have with you are now known by the enemy.

"Public key encryption" works by taking an encryption key and doing a lot of math on it, so that you end up with TWO keys: one that is "public" and one that is "private." You take something and encrypt it with the public key, but the public key can not be used to READ it; once it's encrypted, only the private key can be used to DECRYPT it.

So if I want to talk to you secretly, I create a public key and a private key. I keep the private key secret; nobody except me knows it. I give you the public key. it doesn't matter how; I can broadcast it on the radio or put it on a bulletin board in the town square. Because it can not be used to read messages, it's OK if everyone knows what it is.

Then if you want to say something to me, you take the public key and use it to encrypt the message. Nobody except me can decrypt it; not even you can, once it's encrypted, only the private key can decrypt it.

If I want to send a message to you that's encrypted, you give me your public key. i use it to encrypt the message,a nd now only you private key--which only you know--can read it.

Mac OS X exchanges login passwords that way. If I connect to your computer, what happens is that your computer sends me its public key. My computer encrypts my login password using its public key, then sends your computer the encrypted password. That way, people listening in on WiFi or whatever can't get the password. Your computer uses its private key to decrypt the password and then check to make sure the password is valid.

SSL security certificates for the Web work the same way. Your computer, when it makes a secure connection to a Web site, asks the Web site for its public key. Then your computer encrypts everything it sends to the Web site (like your account name or your credit card or whatever) using the public key. The information is sent to the Web site, where only the private key can be used it read it.

Fascinating!

Many thanks for the explanation.

Indeed I have learned much. Little did I know there was so much there there in response to such a simple query.

Merci.

Yes....ditto on the thanks. Quite educational.

ryck