Previous 1 2 Next 18 Replies Latest reply: Nov 12, 2013 6:51 AM by verbekealexis
tcsadmin Level 1 Level 1
Well, I've successfully (I THINK) replaced two of the three certificates that are expiring.

First off - 90% of what's in the Security manual concerning certificates is useless to this issue. I don't want to know how the watch is made - I just want to tell time! In fact there is a GLARING typo on Page 167 of the Snow Leopard Server Security Configuration Manual showing a screenshot of the Certificate Assistant in Server Admin that is just plain wrong!

It's clear there is no way to RENEW the certificate. You have to delete the old one and replace it with a new certificate.

The issue I have is that with all the services using the certificate, I don't know what the impact to the end-users is going to be when I delete that expiring certificate.

It appears that a certificate is created automatically when the OS is installed, although I installed the OS Server on a virtual machine and I didn't see where it got created, nor was I given any input during the creation (like extending the expiration date).

I don't know whether those certificates are critical to the running of the OS or not, but I went through the process of creating a new certificate in Server Admin. I deleted the expiring certificate. Because the two servers on which the expiring certificate was deleted does not have any services running that require a certificate (such as SSL on my mail server), nothing bad seems to have happened or been impacted negatively.

I did, however, name the new certificate the exact same thing as the old certificate and tried to make sure that the parameters of the new certificate were at least as extensive as the old certificate. You can look at the details of the old certficate to see what they were.

Here's the "critical" area of the certificate that was "auto-created" on my virtual server. (It's the same as the one on my "real" server.

Note the "Public Key Info" for "Key Usage": Encrypt, Verify, Derive. Note the "Key Usage" Extension is marked CRITICAL and it's usage is "Digital Signature, Data Encipherment, Key Cert Sign". Extended Key Usage is also critical and it's purpose is Server Authentication.

Here's a screenshot of the default certificate that's created if you create a new self-signed certificate in Server Admin:

Note the differences between the two certificates. It LOOKS to me like the second certificate would be more expansive than the default issued at OS Install? Although I don't really care about Apple iChat Encryption.

Be aware that creating certificates starts to populate your server Keychain.

It appears that when you start to delete certificates, it leaves behind private keys.

If you delete these keys you get a message warning you about the end of the world if you delete private keys. I'm sorry if your world melts around you, but I'm going to delete them from my Keychain.

OK, now I'm going to try to create a certificate that is similar to the one that is created at start-up.

In Server Admin, highlight your server on the sidebar and click the "Certificates" tab in the icon bar.

Click the "+" button under your existing certificate and select "Create a Certificate Identity". (This is how I created the default certificate we just got through looking at except I clicked through all the defaults.)

Bypass "Introduction".

In the "Create Your Certificate" window I set the "Name" as exactly the same as the name of the expiring certificate. I'm HOPING when I do this for my email server, I won't have to go into the services using the certificate and select the new one. On the other hand, naming it the same as the old one could screw things up - I guess I'll know when I do it later this week.

The "Certificate Type" defaults to "SSL Server" and I think this is OK since that's what I'll be using this certificate for.

You HAVE to check the "Let me override defaults" if you want to, for example, extend the expiry period. So that's what I want to do, so I checked it.

In the next window you set the Serial Number and Validity Period. Don't try typing "9999" (for an infinite certificate) in the "Validity Period" field. Won't work - but you CAN type in 1826 (5 years) - that works - Go Figure!??? You can type in a bigger number than that but I thought 5 years was good for me.

The next part (Key Usage Extension) is where it gets sticky. OF COURSE there is NO DOCUMENTATION on what these parameters mean of how to select what to choose.

(OK here's what one of the "explanations" says: "Select this when the certificate's public key is used for encrypting a key for any purpose. Key encipherment is used for key transport and key wrapping (or key management), blah, blah, blah, blah, blah blah!") I'm sure that's a clear as day to you rocket scientists out there, but for idiot teachers like me - it's meaningless.

Pant, pant...

The next window asks for an email address and location information - this appears to be optional.

Key Pair Information window is OK w/ 2048 bits and RSA Algorithm - that appears to be the same as the original certificate.

Key Usage Extension window

Here's where it gets interesting...

I brought up the screenshot of the OS Install created certificate to guide me through these next couple of windows.

Since the expiring cert had "Digital Signature, Data Encipherment, Key Cert Sign" I selected "Signature, Data Encipherment and Certificate Signing".

Extended Key Usage Extension...

Hoo Boy...Well, this is critical. But under "Capabilities" it lists ANY then more stuff. Wouldn't you THINK that "ANY" would include the other stuff? Apparently not..."Learn More"?

Sorry, folks, I just HAVE to show you the help for this window...

+*The Extended Key Usage Extension (EKU) is much like the Key Usage Extension (KUE), except that EKU values are defined in terms of "purpose" (for example, signing OCSP responses, identifying an SSL client, and so on.), and are easily extensible.  EKU is defined with object identifiers called OIDs.  If the EKU extension is omitted, all operations are potentially valid.*+


OK (holding my nose) here I go...Well, I need SSL Server Authentication (I THINK), I guess the other stuff that's checked is OK. "Continue".

Basic Constraints Extension...

Well, there is no mention of that on the original certificate, so leave it unchecked.

Subject Alternate Name Extension...

Nothing about that in the original certificate, so I'm going to UNCHECK that box (is your world melting yet?)

DONE!!!! Let's see what the heck we got!

Well, I don't know about you but that looks pretty close for Jazz?

I got some extra crap in there but the stuff from the original cert is all there.

Think we're OK??

Out with the old certificate (delete).

Oh oh - extra private key - but which is the extra one? Well, I guess I'll just keep it.

Oh more thing in KeyChain Access...

See the red "X" on the certificate? You can get rid of that by double clicking on the certificate and expanding the "Trust" link.

Select "Always Trust".

I don't know if that does anything other than get rid of the Red "X", but it looks nice. There seem to be plenty of certificates in the Keychain which aren't trusted so maybe it's unnecessary.

I've done this on both my file server and my "test" server. So problems. Thursday I'll go through this for my Mail server which uses SSL. I'm thinking I should keep the name the same and not replace the certificates in the iCal and Mail service which use it and see what happens. If worse comes to worse, I may need to recreate the certificate with a different name and select the new certificate in the two services that use it.

Look...I don't know if this helps anyone, but at least I'm trying to figure this idiocy out. At least if I screw up you can see where it was and, hopefully, avoid it yourself.

If you want to see my rant on Apple's worthless documentation, it's here.

MacBook Pro
  • Level 1 Level 1
    Well, I put off updating the email server certificate until the absolutely last minute...well, I had 24 hours to go. Interestingly enough, when I created the new certificate, all the checkboxes for it matched the existing certificate. The only thing I really had to change was the date of expiry and the contact information. We'll see how it all turns out tomorrow.
  • Level 1 Level 1
    Learning as I go along...I suppose it was naive of me to think just creating the certificate was enough.

    When I deleted the old certificate, it was stripped off of the services that were using it: email, iChat and Web services. Almost as soon as the old certificate was gone, I started getting email bounce messages.

    All I had to do was go into Server Admin and go to each of the services that were using the old certificate and populate the appropriate fields with the new certificate.

    Of course, the clients need to accept the new certificate on their end.

    I'm hoping that's all there is to it.
  • e.f. Level 1 Level 1
    this is very useful, thanks for posting. i'm renewing a self-signed cert used for AB and iCal that's about to expire. i feel your pain on the server documentation inadequacies. why they call it "renew" is a mystery, as it seems the only choice is to create a new cert, manually copy all the settings, replace the old one, then manually update all services using it. why can one not simply update the expiration date? (i'm sure there's some obscure security justification for this, but still.) i read through your posts, but it would be great if, after your experience, you could summarize the steps to take with settings one might overlook...
  • Kriener Level 1 Level 1
    Same problem:

    How can u i update the certificate with a self signed new one, without going through all services an update the SSL certificate manually?

    Is there a way to replace the certificate, which is automatically assigned in the services (mail, web, ...)

    Greeting from Germany
  • Rob Rocket Level 2 Level 2

    I have setup up a dozen testservers (ran into every deadlock I could to play around and finally have setup two real life servers with everything running except email.

    I watched the 9 hour online video tutorials from "Mac OS X Server 10.6 Snow Leopard Essential training" from Sean Collins. (Some parts I viewed again and again...

    So right now I also use self signed certs I would love to hear from someone who has watched his explanation in Chapter 5. SSL where he shows how to renewin easy steps.

    The way how he does it is well explained and I would love to hear from someone who has done this in his way alredy.
  • e.f. Level 1 Level 1
    i don't have a lynda subscription, perhaps you could provide another link to the relevant section, or summarize the steps he takes?
  • Kriener Level 1 Level 1
    I didn't have an account too

    Today tryed it with setting up an "Certificate Authority" on the server. Creating a CSR in Server Admin, creating a new certificate with this CSR in "Keychain Access" and finally imported the new certificate with Server Admin as an replacement certificate:

    Still the same problem

    The old certificate is replaced with the new one, but it isn't assigned in the different services. "Select a certificate" is all what i can see, then i had to choose the new one, save the service settings, and everything went back working fine.

    Any ideas?
  • Rob Rocket Level 2 Level 2
    I would love to post, but I think I will get into copyright problems if I do this. :-/

    The explanation runs for 10 Minutes or so and there is a transcript as well, but you have to be a member to access that.

    If you have the time to wait I will post my experience after I have done it myself, but I am not so far in the process to make it now.

    A one month subscription of lynda costs around 25 US-$ and it really pays for itself.

    all the best
  • e.f. Level 1 Level 1
    i actually bought a lynda subscription specifically for that Server course, but i found it left out too many crucial details to be worth it. it would be very clear about some things and very unclear about others, assuming you knew certain things. so i cancelled.
  • Rob Rocket Level 2 Level 2
    I am sorry to hear that. I thought it might be of help, because for me everything else was very clear and worked out as expected
  • e.f. Level 1 Level 1
    so how did your experience go? did everything go smoothly?
  • e.f. Level 1 Level 1
    to add to countryschool and john orban's experiences:

    using the + Create a Certificate Identity button in Server Admin is the same thing as running KeyChain Access and selecting Certificate Assistant from the app menu, and choosing Create a Certificate. Note that you don't need to create a Certificate Authority first.

    in the second "extended key usage extension" dialog box, i UN-checked Any, PKINIT Server Authentication, and iChat Encryption. this produced the closest match to the server's default self-installed certificate.

    when updating trust settings in Keychain Access, the best match to the original cert are custom settings - set Always Trust for only SSL and X.509 Basic Policy.

    supposedly you can use Replace With Signed or Renewed certificate button from Server Admin and avoid needing to re-assign to services. however i was unable to get this to work because my new cert didn't match the private key of the old. for those interested in going further, i did figure out the following which might be helpful:

    you can't drag and drop a cert from Keychain Access or Cert Manager. you need the actual PEM file. supposedly you can hold down the option button while dragging, but this didn't work for me. however you can view the certificates directly in etc/certificates. but that folder is hidden by default. a useful shortcut is to use Finder / Go To Folder, and type in "/private/etc/certificates"

    now, on my system the modification date was the same for old and new certificates. why? because it seems to be set by when you last viewed them. so how do you know which is which? answer: compare file name to SHA1 Fingerprint at bottom of certificate details.

    after you delete the old certificate, it will disappear in Keychain Access from "System" keychains. however in "login" keychains the old one will still be there but the new one won't. it seems to make sense to delete the old one from here and add the new one. somebody tell me if this is a bad idea. the + button does not work easily for this, you need to drag and drop from the etc/certificates folder.

    lastly, the "common name" field is the server/host name the client will try to match to. you can use wildcard for this, e.g. * if you need to, you can use the Subject Alternate Name to provide an alternative name to match to, in which case the common name field will be ignored, which is why by default the dNSName alternate field defaults to the common name. more info here:

    maybe that's hopeful to somebody. but i stopped there since things seem to be working.

    last note, which you probably know already - if you don't want to bother installing the certificate in your client computers and phones, you can select Details when the first trust warning pops up and select Always Trust.

    now, we'll see how everything works once people start really using it...
  • OliverSL Level 1 Level 1
    What can I say, epic post!

    Many thanks, I just created a new certificate and delete the old. Then changed all services to use the new certificate.

    The doc is not clear enough, thanks for the detailed info
  • 2W Level 1 Level 1

    Thanks, it did the trick for me after having first deleted the old certificate.

Previous 1 2 Next