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?