An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Bad Keychain Certificates?
#17440 09/16/11 10:34 AM
Joined: Aug 2009
OP Offline

Joined: Aug 2009
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.


Harv
27" i7 iMac (10.13.6), iPhone Xs Max (12.1)

Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bad Keychain Certificates?
Pendragon #17441 09/16/11 11:22 AM
Joined: Aug 2009
Likes: 14
Offline

Joined: Aug 2009
Likes: 14
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

Last edited by ryck; 09/16/11 11:22 AM.

ryck

"What Were Once Vices Are Now Habits" The Doobie Brothers

iMac (Retina 5K, 27", 2020), 3.8 GHz 8 Core Intel Core i7, 8GB RAM, 2667 MHz DDR4
OS Ventura 13.6.3
Canon Pixma TR 8520 Printer
Epson Perfection V500 Photo Scanner c/w VueScan software
TM on 1TB LaCie USB-C
Re: Bad Keychain Certificates?
ryck #17448 09/16/11 08:27 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
> "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.

Last edited by artie505; 09/16/11 08:29 PM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bad Keychain Certificates?
Pendragon #17449 09/16/11 08:40 PM
Joined: Aug 2009
Likes: 1
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 1
This is quite likely related to the issue discussed in Security Updates.


alternaut moderator
Re: Bad Keychain Certificates?
alternaut #17450 09/16/11 08:47 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: alternaut
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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bad Keychain Certificates?
Pendragon #17451 09/16/11 08:51 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
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. smile

Neither of these is related to the DigiNotar certificate revocation.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Bad Keychain Certificates?
tacit #17453 09/16/11 09:04 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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.)


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bad Keychain Certificates?
artie505 #17456 09/17/11 04:04 AM
Joined: Aug 2009
Likes: 14
Offline

Joined: Aug 2009
Likes: 14
Originally Posted By: artie505
> "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?

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


ryck

"What Were Once Vices Are Now Habits" The Doobie Brothers

iMac (Retina 5K, 27", 2020), 3.8 GHz 8 Core Intel Core i7, 8GB RAM, 2667 MHz DDR4
OS Ventura 13.6.3
Canon Pixma TR 8520 Printer
Epson Perfection V500 Photo Scanner c/w VueScan software
TM on 1TB LaCie USB-C
Re: Bad Keychain Certificates?
tacit #17461 09/17/11 05:30 PM
Joined: Aug 2009
Likes: 1
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 1
Originally Posted By: tacit
Neither of these is related to the DigiNotar certificate revocation.

Thanks for correcting my misconception. laugh


alternaut moderator
Re: Bad Keychain Certificates?
artie505 #17465 09/18/11 09:37 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
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.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Bad Keychain Certificates?
tacit #17473 09/19/11 06:50 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Fascinating!

Many thanks for the explanation. smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bad Keychain Certificates?
artie505 #17474 09/19/11 09:19 AM
Joined: Aug 2009
OP Offline

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

Merci.


Harv
27" i7 iMac (10.13.6), iPhone Xs Max (12.1)

Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bad Keychain Certificates?
tacit #17477 09/19/11 01:56 PM
Joined: Aug 2009
Likes: 14
Offline

Joined: Aug 2009
Likes: 14
Yes....ditto on the thanks. Quite educational.

ryck


ryck

"What Were Once Vices Are Now Habits" The Doobie Brothers

iMac (Retina 5K, 27", 2020), 3.8 GHz 8 Core Intel Core i7, 8GB RAM, 2667 MHz DDR4
OS Ventura 13.6.3
Canon Pixma TR 8520 Printer
Epson Perfection V500 Photo Scanner c/w VueScan software
TM on 1TB LaCie USB-C

Moderated by  alternaut, dianne, dkmarsh 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.027s Queries: 40 (0.019s) Memory: 0.6382 MB (Peak: 0.7407 MB) Data Comp: Zlib Server Time: 2024-03-28 14:40:53 UTC
Valid HTML 5 and Valid CSS