PositiveSSL certificate reported as signed by an unknown authority

Some background: Digital certificates are little more than some fancy math that's traceable back to some math that's (hopefully) been pre-loaded into the client's list of known (and trusted) certificates, either directly or through what are known as intermediate certificates, and the trust that any of the hundreds of certificate vendors and their many vendor partners involved won't generate a rogue certificate.

If your certificate is not recognized, then you either don't have the matching root certificate, or there's a missing intermediate certificate that'll get this particular client certificate traceable back to the root certificate, or you have a bad or corrupt certificate.

It's been my experience that Comodo (vender of Positive SSL certificates) does require intermediate certificates. Here's a somewhat related discussion. Here's the Comodo support site, and they have a troubleshooting tool, and they also have downloads for the intermediate certificates.

Alternatively, check with the Comodo ceritficate vendor support folks, or "return" this certificate and acquire a certificate from another vendor that either provides the intermediate certificates or doesn't need intermediate certificates.

Or if you're working locally and only with systems you can control and can load your own certificates, you can just use a self-generated certificate. Other than the initial load of the root certificate or of initially trusting the certificate if you're not running your own certificate root and associated chain (and barring loss of your private key; the "password" to your certificates), self-signed equivalent-strength certificates are as secure as the purchased certificates.

Check with Comodo directly. I've had occasional issues with Comodo certs in the past, both around the intermediate cert and around corrupt certs.

Make sure Server.app has your purchased certificate selected.

I'd also look to reboot, on the off chance some part of the certificates got tangled. (I've seen that on occasion, too.)

FWIW, it's rather less black magic than it is a profit center that's based on some math, and on having a root certificate that's installed and present in enough of the clients.

Just double click your certified certificate in keychain manager and then scroll down until you see the URI of the PositiveSSLCA2.crt. Click on the link and load this certificate to your keychain. Afterwards your Certificate will have all the necessary certificates of the complete chain and will be signed green.

I know this post is over 1 year old but I have the same error message and may have a clue to what is the issue, for the benefit of others who will read this post.

I have a Mac Mini with Mac OS X 10.10.5 (Yosemite) running OS X Server 4.1.5.

When I connect from my iMac at home, using OS X Server, I see the same message, mentioned in this post, in red: "This certificate was signed by an unknown authority". However, when I connect through Remote Desktop to the Mac Mini and connect locally using the OS X Server, I see the message in green: "This certificate is valid".

The difference is I have not yet upgraded my iMac at home yet and still run Mac OS X 10.10.4 and OS X Server 4.1.3. I suspect there is an compatibility problem with the newer version of OS X Server (4.1.5) and the version I have at home (4.1.3) and the Certificates module is unable to read the information correctly OR it is because I'm connecting remotely.

So my recommendation is to make sure you have everything up-to-date (Mac OS X and OS X Server) and when dealing with SSL certificate installation on your server, do this directly on the machine (through Remote Desktop is OK) and not with the OS X Server app remotely connecting to the server.

If the message persist after these steps, you may have a real problem. Otherwise, it was just a glitch due to either the version of your OS X Server app or the fact you were connecting remotely.

I will upgrade my iMac at home and retest to valide the issue was with the version differences between my OS X Server apps and not with the fact I was connecting remotely.

I hope this helps!

Older versions of Server are not as secure. It would be prudent to upgrade to at least Server 3.2.2

Server prior to version 3.2.2 for 10.9.5 has a Security hole where devices connecting can say, "I don't want TLS encryption, I want good-old SSL" (which has recently-discovered Security holes in it) and get SSL.

Server 3.2.2 and later insist on more-secure TLS or connection is refused.

(update regarding my previous reply)

I upgraded my local Mac OS X to 10.10.5 and my local OS X Server app to 4.1.5. When connecting to my Mac Mini server using OS X Server from my iMac, I still see the message in red: "This certificate was signed by an unknown authority". If I connect on the server with Remote Desktop and use the OS X Server from the server itself, I see the message in green: "This certificate is valid".

I conclude this is either a glitch in the OS X Server or a limitation that cannot be resolved, and when it comes to managing certificates, you better do this directly on the server itself to avoid some potential issues.

greengaroo wrote:

(update regarding my previous reply)

I upgraded my local Mac OS X to 10.10.5 and my local OS X Server app to 4.1.5. When connecting to my Mac Mini server using OS X Server from my iMac, I still see the message in red: "This certificate was signed by an unknown authority". If I connect on the server with Remote Desktop and use the OS X Server from the server itself, I see the message in green: "This certificate is valid".

I conclude this is either a glitch in the OS X Server or a limitation that cannot be resolved, and when it comes to managing certificates, you better do this directly on the server itself to avoid some potential issues.

For your case, you're going to have to look at the certificate chains involved and the intermediate certificates, and you'll want to see if the DNS translations are the same for both paths. The behavior you're describing could be that the certificates do not match the reverse DNS (IP address to name) domain names being used, as the domain names differ based on the access path. If the paths have different names, then you'll need a multiple-domain or wildcard certificate, or you'll need to sort out the DNS to have the same name used via the various paths.

To see the reverse translation, launch Terminal.app from Applications > Utilities and issue the following command, adjusting the IP address for your local IP address and your public IP address as well as your DNS host name — and yes, I'm assuming NAT is in use here. $ is the command prompt, and what follows is the command you'll enter. The next line is the response.

$ dig +short yourservername.example.com

192.0.2.10

$ dig +short -x 192.0.2.10

yourservername.example.com

$

You'll want to issue those commands in the various network contexts where you're testing access from, too — from your private NAT'd network and (presumably) from somewhere on the public internet.

If the reverse does not match the domain or host name on the certificate, that'll cause certificate validation errors of the sort you're reporting.

In general, please consider starting a new thread, and not resurrecting an older thread. Mixing discussions and problems just gets me confused, as we're now discussing what may be different errors or behaviors or causes, different versions, different solutions. It can get other readers, confused, too. Your case involves different IP routing paths which AFAICT the base thread does not, for instance. If you're sure that the problem in the new thread is the same as the old one, then certainly reference the older thread for background.

Thank you for your reply.

I can tell you the certificate chain is correct. I double checked with the certificate authority and from their end, they can confirm this is all good.

They did pointed me that the reverse DNS lookup on the IP address is not returning the correct domain name but rather the hostname of the cable modem provided by my ISP. I was planning to contact my them tomorrow to have it fixed, however I didn't imagine this would be the source of my problem. We'll see.

Sorry about resurrecting this post. I stumbled upon it myself while looking for a solution to my problems and thought my two-cents would help people stumbling on the same thread.