Multi-Domain SSL Certs Missing Common Name (CN)

After a few years of using COMODO for our EV Multi-Domain certificates we have recently run into a problem, after we purchased a new EV Multi-Domain Cert.

It seems that COMODO in thier wisdom have removed the property ‘Common Name’ (CN) from the subject properties in the SSL details. This causes major problems when users are trying to view your secure pages from behind a corporate firewall with outbound HTTPS filtering switch on and prevents the user from accessing the page as it fails validation.

We’ve had lots of support calls coming in because of this issue and after trying to resolve the problems with COMODO, they finally told us that they can’t add the CN property full stop! However they did surgest buying a non EV multi-domain certificate, which we did, but that also had the same problem.

We’ve now had to go to GlobalSign for a certificate and requested refunds for the £1800+ spent on the useless COMODO certificates.

Warning for anyone needing a multi-domain certificate.!

Strange, I have a very recent EV MDC and it has one name in the Subject CN, all others are part of Extensions, Subject Alternative Name.
They can also issue with all names in the CN field.

I’m sorry you had trouble with our service. It wasn’t Comodo’s doing per se as it was a requirement from the CA Browser Forum (CABForum), which is something all publicly trusted CAs must follow (e.g. GlobalSign and ourselves). As per the CABForum if a CN is present, it MUST be a single FQDN or IP. In the past, some legacy applications did not accept the SAN extension and thus several CAs were adding multiple CNs to the Subject area. The CABforum now discourages and has deprecated adding multiple CNs to the Subject area because these legacy applications that existed in the past should have already be deprecated themselves since they’re ancient and quite possibly are a security risk.

The lack of a CN shouldn’t be the reason a certificate fails validation. One of the major reasons that a certificate will fail validation is because the “client” (browser) is unable to reach the CRL or OCSP responder for the issuing CA. Since you said that filtering of some kind was enabled, this seems VERY likely this was the case.

This would seem to indicate the lack of a CN WAS NOT the issue and something else is wrong either on the certificate side or server’s certificate configuration.

==

Furthermore, would you be willing to PM me with your ticket ID so that we may address this issue internally?