Server 3 / SSL Certificate / Open Directory - Problem!

I don't understand.

I've just configured my server with my brand new godaddy *.domain.com certificate and it sticks just fine.

With Open Directory OFF it wouldn't stick, but as soon as I flicked on the switch for OD, I was able to go back to the Certificates tab and select my wildcard certificate.

One thing I will say...

Before I tried that, I copied the cert into keychain access along with the intermediate, then moved them down to the system tab. I had to type my username and password, but it copied fine. It took about 30 seconds for the certificate to appear in the list of available ones in server.app, but sure enough... It popped right up.

The only thing I can think maybe I did that's out of the ordinary is I clicked on the gear and chose "Show all certificates." before I selected it.

Contacted Comodo support and this there answer

Hello,

Apple has yet to address the issue as far as we're aware so there is no known solution that we are aware of at this time.

Kind Regards,

Technical Support

--

Comodo Technical Support

Edited with update: Had the same issue with a Comodo Wildcard SSL cert. All services would accept the certificate except Open Directory. Tried importing the cert a number of different ways (through server.app, through keychain, as root, not root), also tried reinstalling and detroying/rebuilding OD, nothing would work. Purchased a Rapid SSL wildcard cert, and had the same issue until I removed and re-configured open directory. At this time the server seems happy with the rapid ssl wildcard certificate on all services (including OD). I even crossed my fingers and rebooted and everything seems to be OK still.

TLDR: Switched to RapidSSL wildcard cert and everything appears to be working.

After 5 months of silence Apple Bug Reporter ask me for more information. (al those months still giving input that the updates don't solved the problem) I told Apple that I had to move on and that I can check the requested on my test server, did that and the next message was that they close the call because it was a duplicate of call 17396241. (it was a duplicate from the beginning)

Several clients have had this issue. The most common cause is not importing the supporting certificates when importing your certificate.

My general fix is this:

1. Make sure your certificate has an organization in the subject area. Note that it should also have an organization name in the issuer area. I use startssl.com

2. Make sure that you import all the supporting certificates at the same time as you import your certificate.

3. If you failed in to include the supporting certificates then reinstall

*** Instructions to reinstall your certificate:

(Note that to export your private key from keychain access you need to start it as root)

Find your certificate and export both the private key and the certificate. Then reimport using the server app.

*** end instructions

4. Make sure your ldap server is not using ssl as this will prevent it from replacing the certificate:

Server app -> Certificates -> Custom -> Open Directory: None

in terminal:

sudo slapconfig -getldapconfig

if ssl: on then:

sudo slapconfig -setldapconfig -ssl off

Using server app, set the certificate to your certificate.

Happiness.

Ok all. Figured this one out!!!

Open Directory requires a SSL certificate that includes a 'Code Signing extension'. See: http://www.comodo.com/e-commerce/code-signing/code-signing-certificate.php

The cheapest form of a Comodo SSL certificate does not include in the SSL Certificate, the Code Signing extension. If you purchase a SSL Certificate from any company, it must include the Code Signing extension. Some of Comodo's SSL certificates include this extension and some don't. The cheapest SSL certificate from Comodo (which I did originally purchase for $9.00 and works for everything but Open Directory) does not include it. Surprise, surprise. Other resellers may include the Code Signing extension in all of their SSL certificates but typically those SSL certificates will be more expensive. If you don't need Profile Manager to use Open Directory with a 3rd party CA, then you are just fine with the self-signed certificate that Apple's Server can create. It is all about that one time 'Not Verified' that will appear in red that a user has to ignore. If you wish for the most proper installation, you will want the complete 3rd part SSL certificate that includes the Code Signing extension.

While Apple's Server prior to Version 3 may have allowed a SSL certificate without the Code Signing extension for Open Directory, it would have been an error on Apple's part. The code signing extension provides a check on the code of the Profile file that the user downloads after the Profile Manager created it. Understandably, an admin would want to ensure that the Profile that a user is installing has not been modified. Thus this extension of the SSL certificate is necessary. Only Open Directory makes use of this SSL extension, thus only the Open Directory service will not be happy with a SSL certificate that does not include this extension. There are many other extensions that a SSL certificate might include, but it is only the Code Signing extension that is important in this situation. The other services of Apple's Server do not deal with the code of anything. They just authenticate the 'who', not the 'what'.

See my reply at the end of the thread for the answer to this problem.https://discussions.apple.com/thread/5531227?answerId=26521867022#26521867022&tstart=0#26521867

I've had this problem for a long time, until today.

Anyway, today, I decided to completely replace my certificates. This is fairly easy for me: I run my own PKI under Open BSD.

I replaced Mavericks server certificate, and had the same problem with Open Directory as always. I then realised I'd forgotten to update my certificate revocation list (CRL). I did so, and when back to Server, and, lo, Open Directory accepted the certificate!

I don't expect this will cure most people's problems, but I do think it's another thing to check. If you're ultimately using a third party issued certificate, as many will, it may be worth checking with the certificate issuer how, and if, they maintain their CRLs.

If you use the link that I provided for Comodo, you will get to their page that specifically addresses their SSL that include the code signing. Do use the link for an understanding of Comodo & this type of certificate. Code Signing is not really all that special but it is distinctly not available it the cheapest forms of SSL certificates. Every major SSL provider will sell an SSL certificate with Code Signing, including Comodo, but it will not be the cheapest certificate that they sell.

The most basic of SSL certificates will give you a lock and a https in the browsers address bar (If that SSL provider has a chain of authority that that browser recognizes.)

Some SSL certificates have extensions that allow for greater features and the require additional checks by the SSL provider beyond the secure transmission that a basic SSL certificate allows. In the address bar for this thread, you will likely see 'Apple Inc. [US]' just after the lock. That is due to an extension within the SSL certificate. A business such as a bank etc, will want to purchase this type of SSL to show that it has been verified to exactly who it is so that the user can be assured that they are not on an impostor site. When a user wishes to receive a file from the SSL certificate owner, the user probably wants to know that the certificate has not been changed along the way. That is the Code Signing extension that Profile Manager needs when it provides a piece of 'code' within the download or attachment. Do send that link to the Comodo customer service rep as they are definitely capable of providing the proper type of SSL certificate.

There are specific code signing certificates and normally sold separately. I have got an ssl from GeoTrust that is accepted to secure all the services including OD and with no code signing extension.

Comodo or AlphaSSL are not accepted by Open Directory.