Home › Forums › OS X Server and Client Discussion › Questions and Answers › 10.4 (Tiger) Server Admin protection problems handling SSL certificates
- This topic has 5 replies, 3 voices, and was last updated 19 years, 1 month ago by
mdomenici.
-
AuthorPosts
-
June 22, 2005 at 11:55 pm #362067
ChrisRyland
ParticipantUsing the new 10.4 Server Admin / server / Settings / Certificates control panel, I bought a QuickSSL certificate from GeoTrust for new.emsoftware.com (our Xserve box), and installed it. I *didn’t* give the certificate a private key passphrase.
But then nothing worked with it–when I enabled SSL in my mail client, I got log messages about not being able to access new.emsoftware.com’s certificate. Ditto for Postfix SSL SMTP, and ditto for Apache’s https support.
OK, quick check:
new:/etc/certificates cpr$ ls -lta total 352 drwxr-xr-x 149 root wheel 5066 Jun 21 21:06 .. drwxr-xr-x 13 root wheel 442 Jun 21 21:06 . -rw-r--r-- 1 root wheel 141865 Jun 21 21:06 x509anchors.pem -rw-r--r-- 1 root wheel 948 Jun 21 18:49 new.emsoftware.com.chcrt -rw-r--r-- 1 root wheel 1265 Jun 21 18:49 new.emsoftware.com.crt -rw-r--r-- 1 root 29 2156 Jun 21 18:49 new.emsoftware.com.crtkey -rw-r----- 1 root 29 891 Jun 21 18:49 new.emsoftware.com.key -rw-r----- 1 root wheel 676 Jun 21 16:34 new.emsoftware.com.csr -rw-r--r-- 1 root wheel 0 May 24 18:55 .defaultCertificateCreated -rw-r--r-- 1 root wheel 660 May 24 18:55 Default.crt -rw-r----- 1 root wheel 1547 May 24 18:55 Default.crtkey -rw-r----- 1 root wheel 534 May 24 18:55 Default.csr -rw-r----- 1 root wheel 887 May 24 18:55 Default.key
and, sure, enough, new.emsoftware.com.key can’t be read by any of those servers, which aren’t running as root, and which aren’t in the wheel group. (I changed the 29 group to wheel, and it didn’t make any difference.)
OK, so I set .key to 744 (world-readable), and then everything works.
But once I fiddle with certificates again in Server Admin, they’re reset to 740, and nothing works.
Here’s the problem: I realize making them world-readable is a no-no, especially since there’s no private key passphrase to protect them. In practice, this isn’t a problem on this server, since there are only a handful of trusted people who log in here, but, still, this seems like a bug.
And how would these be protected unless one used ACLs to give specific access to the system users (cyrusimap, www, etc.) who need them?
Seems like this should Just Work out of the box, and not require my fiddling around.
Anyone else had good luck with the new certificate handling in 10.4?
June 23, 2005 at 2:45 am #362072ChrisRyland
Participant[QUOTE BY= MacTroll] Most apps, Postfix and Apache, start off life as a root process and then drop their root privs once they’ve started up and running.
In many cases this allows them to cache the cert as root and then use it when they’ve dropped their root privs.
I haven’t used a purchased cert on 10.4 yet, but all the self-signed ones I’ve done have worked fine.
You might want to give the cert assistant in Keychain Manager a go. Its MUCH more powerful than what server admin has.[/QUOTE]
Thanks, but though they *could* do this, none of them seem to do it.
Thanks for the tip re Keychain Manager, but I’m all set with acquiring the cert.
August 18, 2005 at 3:27 pm #362840ChrisRyland
ParticipantTurns out this was a bug in the Tiger release when upgrading.
10.4.2 fixes the bug.
March 20, 2006 at 1:14 am #365743mdomenici
ParticipantThere’s also another bug where even though Server Admin shows your certificate as selected, it really isn’t.
This frequently happens when you are upgrading from a self-signed cert to a signed one from a CA. The common names stay the same.
The best way to fix this is to go in one-by-one to the effected services, switch them to the Default certificate, save, restart the service, and then change back to certificate again, save, and restart the service.
I had this problem when I switched cert vendors and had a self signed cert in between.
– Matt
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed