PDA

View Full Version : "not trusted" Apple root certificates




goscuter1
Dec 13, 2011, 05:59 AM
http://forums.macrumors.com/attachment.php?attachmentid=315939&stc=1&d=1323777342

I get endless root certificates installed which Keychain says are bogus. Why do they find their way into my root certificate stores if they're bogus? Isn't the point of the store to - not - allow that?

nb. some of these certificates are installed with a clean install of Lion.



Mr. Retrofire
Dec 13, 2011, 07:37 AM
Image (http://forums.macrumors.com/attachment.php?attachmentid=315939&stc=1&d=1323777342)
I get endless root certificates installed which Keychain says are bogus

It is a self signed certificate, and therefore not useful in the communication with third parties. If you need a verified certificate, follow this guide:
http://www.jonsblog.org/2011/07/16/10-6-8-installing-ssl-certificates-correctly/

goscuter1
Dec 14, 2011, 04:09 AM
If you need a verified certificate

Thanks for helping out - that's the question I suppose I really should be asking I guess? I read the article you linked - cheers! But I'm confused. I don't have a server? I don't ever believe I ever need to mount remote filesystems? My laptop and desktop have no need to ever connect to each other.

What do I need Kerberos passwords and logins and certificates for? When Lion is clean installed with an Apple Store USB thumb drive, onto a zero-filled hard drive, it installs "untrusted certificates", hidden server nodes, I'm not 'permitted' to unmount these read-only mapped drives or whatever these mount entries are:

http://forums.macrumors.com/attachment.php?attachmentid=316044&stc=1&d=1323856463

I have all these hidden DS_Store dot files, in every folder on every drive. This is reminding me of when I bought Windows 7 Ultimate and discovered I had gone and bought a Server without realising it. Had no need for it, couldn't possibly want the security vulnerabilities, but thankfully no one told me so I didn't notice until my OS stopped operating my systems. 50 million files a few hours after a clean install. Impressive stuff. No I didn't feel stupid then, I don't believe anyone mentioned a word of the illogical 'development' to me. I found out Windows 7 = Servers on Google. This is remarkable, because they're still selling Windows Server...servers.

I see OS X Lion are now Servers. My 13" Macbook Air is a server, and no one mentioned this wonderful news to me again. Well isn't that something. I feel a little more stupid this time, but then it's all a bit creepy if you ask me.

I didn't used to have these hidden DS_Store dot files. I have Apache and OpenDirectory and stuff I'd like to never have to deal with, if it were up to me.

Is there a way I can decline - thanks, but no thanks etc?

goscuter1
Dec 30, 2011, 10:10 AM
It is a self signed certificate, and therefore not useful in the communication with third parties. If you need a verified certificate, follow this guide:
http://www.jonsblog.org/2011/07/16/10-6-8-installing-ssl-certificates-correctly/

I don't need a verified certificate. I need to understand why "untrusted" certificates for Keberos etc are continually showing up, after being inserted by Lion during 'clean' installs.

If it's not useful in communicating with third parties, what is its use or function or reason for existence?

chown33
Dec 30, 2011, 05:37 PM
I don't need a verified certificate. I need to understand why "untrusted" certificates for Keberos etc are continually showing up, after being inserted by Lion during 'clean' installs.

If it's not useful in communicating with third parties, what is its use or function or reason for existence?

Google search terms: com.apple.systemdefault root certificate

In the top few results:
http://support.apple.com/kb/TS1452

See the Additional Information sub-heading on that page.


I have all these hidden DS_Store dot files, in every folder on every drive. ...
Google search terms: DS_Store

The top result:
http://en.wikipedia.org/wiki/.DS_Store


Regarding .Trashes (which is not a mount point, BTW)...

Google search terms: ".trashes" mac

The top result:
http://www.westwind.com/reference/os-x/invisibles.html

(The quoting of .trashes in the search terms ensures google doesn't strip the leading dot.)

goscuter1
Dec 30, 2011, 10:42 PM
Thank you Sir for the effort you went to, and I appreciate this topic would be a yawn for you but then I'm not entirely sure that yawning can be correct here. Because...I had read a couple of these already, and have read them all (and more) now, but the questions remain un-answered (I believe).

Google search terms: com.apple.systemdefault root certificate

In the top few results:
http://support.apple.com/kb/TS1452

See the Additional Information sub-heading on that page.

Important: You should not modify or delete the "com.apple.kerberos.kdc" certificate or key pair from Keychain Access, even if the certificate is marked as "This root certificate is not trusted."

Additional Information
Starting with Mac OS X 10.5 Leopard, each Mac OS X client maintains a local KDC for use with Bonjour and peer-to-peer security. This means it is a part of Back to My Mac (.Mac), local file sharing, and Leopard Screen Sharing.

That's all good and well, but I don't use Bonjour. I have zero desire to connect to peers. I will never use Back to My Mac, I have no requirement nor any desire to share files (either locally, or remotely), and the same goes for sharing my screen.

So I wish to remove these exploits which I don't need. Apple CS may or may not have touched a computer before, between them. I have been given no evidence whatsoever to believe that they have any idea whatsoever about anything Apple / MacBook Air / Networking / Lion / Computer related.

During the installation of Mac OS X 10.5, a computer-specific security certificate named "com.apple.kerberos.kdc" is created and entered into the Keychain along with a public/private key pair. This certificate and the associated keys are visible in the System Keychain in Keychain Access. You may notice that this certificate is marked as "This root certificate is not trusted." This is by design, as the certificate is only intended to be accessed by those specific programs and services designed to use local KDC authentication and does not indicate an issue with the certificate or Keychain.

?? This makes very close to zero aka (non)sense. Either it's trusted to perform the limited duties it's ostensibly certified to perform, or it isn't. The above is clearly nonsensical and therefore ludicrous. I've read it 15 times and it just gets more ridiculous each time. I'm calling it out.

Google search terms: DS_Store

The Wiki for DS_Store is entirely unsatisfactory, but then it does link to an adobe.com page which correctly sums up this outrageous imposition.

http://kb2.adobe.com/cps/168/tn_16831.html

When a new directory is accessed using the OS X Finder, a .DS_Store file will be created in that directory. Once the directory is viewed using the Finder a .DS_Store file will be permanently created in that directory. Currently, the option to create a .DS_Store file can not be disabled.

Users should be concerned about .DS_Store files being uploaded to the web servers. Since .DS_Store files contain some vital folder information they can be exploited to obtain information about system configurations. Please see the following third-party link for more information: Apple security updates.

Solution

To avoid creating .DS_Store files, do not to use the OS X Finder to view folders. An alternative way to view folders is to use UNIX command line.

It's an option which cannot be disabled. Some option. To protect against the imposed non-optional security risk, you have the option to not use Lion. This is just ridiculous. There's no other word for it.

After complaints from users about these files being created on remote systems, Apple posted an article on its support site detailing how to disable the creation of remote .DS_Store files over network connections.[5] However, this instruction does not apply for local drives, including USB flash drives.

Apple creates a unnecessary security exploit.
After complaints from users, Apple posts a semi-but-incomplete 'workaround' for users who want to protect themselves from the unnecessary and outrageously invasive incursion into territory which has absolutely nothing to do with Apple or HFS or Finder or OX S.
Apple doesn't remove the security exploit, mind! Users who are unaware or get frustrated with the ridiculous process, are out of luck aren't they?
And finally, there are no 'workaround' solutions whatsoever for portable drives.

Why am I pointing out the obvious, when it's almost 2012? You all have owned Apple machines for a long time, no?

Regarding .Trashes (which is not a mount point, BTW)...

Google search terms: ".trashes" mac

The top result:
http://www.westwind.com/reference/os-x/invisibles.html

(The quoting of .trashes in the search terms ensures google doesn't strip the leading dot.)

This is hardly a reference page worth linking to.

/usr/standalone
Contains boot loader programs for (potentially) various computer architectures. In the installs I've looked at, this is simply a duplicate of the BootX loader (also found in /System/Library/CoreServices/BootX); I'm not sure why both copies are needed.

Yeah that fills me with confidence that he's - clearly - an authoritative source.

Reasons for invisibility

In Mac OS X, there are three different ways a file or directory can be made invisible in the finder: it can have the "invisible" attribute set (as in older Mac OS systems), its name can start with "." (as in other unix systems), or its name can be listed in the /.hidden file. Many of the files and directories listed above are actually invisible for multiple reasons (e.g. /bin is listed in /.hidden, as well as having its invisible attribute set).

Note that OS X only respects the .hidden file on its boot volume, so if you boot from another disk, several normally-hidden files will suddenly be visible. Also, since Mac OS 9 (and older versions) only recognize the invisible flag, even more of these files (mainly /.vol, /mach, /mach.sym, and sometimes .DS_Store) will be visible when you boot into Mac OS 9.

No, it's funny. But not one single REASON was given, in his "Reasons for Invisibility". Perhaps I've missed his reasons? Kindly point them out to me if I have, because I know all about why files are invisible. And it's beyond insulting and offensive to suggest that users would want to be deceived.

For their own benefit, right? hah. Best not to tell them. So creepy, all of this - unbelievably creepy.

But if I may return to my original desire to unhand this forced imposition from my machine, how may I achieve this please (I paid AppleCare $300 for a support extras policy but they've never heard of a computer before). What I'm demanding is not exactly complex. Where is this app gone off to?

http://docstore.mik.ua/orelly/unix3/mac/figs/mud_0303.gif

I imagine it had to be dumped to make way for the 20 language packs which comprise the majority of every English Lion Install ESD image. Which I'm prevented from configuring, I wonder if that's normal actually...

ps. the reference to "mounts" wasn't about the .Trashes file which is another separate outrage altogether because I have OCD, which means, I delete files when I delete them - I do not, recycle them. And it's very insulting to suggest I require an option to 'change' my mind, when the files aren't even deleted by emptying the bin, not even deleted if you securely empty the bin, not even deleted if you reformat your hard drive, not even deleted if you zero-fill your drive. And probably, by that point, some outrageous unnecessary and ambiguiously-described dot files have ferried your compromising data to a safe - remote - location. And I'm yet to be sold on an argument that makes a convincing case that ATA Secure Erase commands do the job, either - but then maybe they do because Apple goes to some great lengths to make such a simple thing, impossible. Yes, impossible. I don't care if you can do it. It's impossible on my MBA. I've spent weeks trying and failing. Whilst AppleCare claims never to have used an Apple computer before, and the Geniuses don't care for the Terminal. And don't know about hidden files. Apparently. What a bunch of creeps.

But anyway, I don't recycle. So therefore, I should have zero .Trashes folders. Instead, I have hundreds or thousands. So someone is lying. But the reference to "mounts" was referring to the below list where my /home and /net folders are auto-mounted for reasons which seem dubious on account of my inability to dismount them (I delete the /etc files but they're just auto-mounted regardless). Impossibly valid question which will never be answered, number 4971.

inDvox
Oct 29, 2012, 05:32 AM
I've done some slight research on this "kerberos" thing and have come up with this conclusion, DON'T GET RID OF IT. Check this link: http://www.finetunedmac.com/forums/u****reads.php?ubb=showflat&Number=17477
Or you can just read the copied text response from FineTunedMac member, "tacit":

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 have messed with this stuff before on other systems because I figured if it isn't "trusted", it shouldn't be on my machine. Well, I was wrong and upon deletion, all sorts of problems cropped up. Programs stopped working correctly, etc.

Hope this helps.
:)