Root cert Error - If no further feedback how do I file a bug with MacBU?

[Pete Shaw]

Hi I posted a message back on September 21st 'Root Cert Errors on Tiger
with SP2' (there is a link to the message at the bottom of this post)

and have had no luck finding any solutions

In summary - I continue to get root cert errors when using Entourage
despite having correct intermediate and root CA certs (we have our own
root CA), all the web help instructions have not helped my scenario. I
can connect to the server through OWA and using openssl command (as
long as I specify a -CApath or root/intermediate certs) without any
errors. I have double and triple checked I am using the FQDN in all
instances and all certs show as valid in all locations (Microsoft Cert
Manager/Keychain).

Since the last mail I have tested directly with back-end server as well
as the front end server and still get the same errors which occur
regardless of connection method (IMAP or Webdav) as long as SSL is
used. If i connect via Apple mail and IMAP over SSL it works fine also
without error. Therefore I can only conclude based on this info there
is an issue with how Entourage verifies certification path.

As noted in the last post this is from OS X 10.4.x (I have tried all .x
revisions), the Exchange Servers are Windows 2003 (SP1) Exchange 2003
(SP1) we will be shortly moving to SP2 on OS and updating Exchange but
as far as I am aware there is nothing specific to SSL in these (and if
its working with other clients. . . .).

If there is not something I am missing can someone suggest the best
procedure to file a bug? is there something similar to Apple's
bug-reporter?

link to old post:
http://groups.google.com/group/micr...1407d49c2efb3d?q=root&rnum=1#f31407d49c2efb3d

 

[Nathan Herring [MSFT]]

Would you mind trying one more thing? Import the intermediates onto the
Microsoft_Intermediate_Certificates keychain, then try again. Let me know
whether that works.

-nh

 

[Pete Shaw]

Nathan,

Thanks for the quick reply - yes I have already done that (sorry I
alluded to it in my first post but could have been clearer). I have
tried different combinations (just in case) including:

User (as we have personal certs) / Server certs > login keychain
Intermediate certs > Microsoft_Intermediate_Certificates keychain
Root Certs > X509 anchors

User /Server Certs & intermediate certs > login keychain
Root Certs > X509 anchors

User / Server certs > login keychain
Root Certs & intermediate certs > X509 anchors

I have also tried logging in as non-admin (authenticating as admin when
necessary) and doing the whole procedure as root/admin user.

From the first post also if I :

sudo openssl s_client -connect servername.region.dev.domain.tld:443
-CApath ~/Desktop/certs

it works fine (as long as I rehash the certs folder after copying
intermediate and root to that location), If I don't specify the -CApath

I can connect but get 'depth=1 /O=rootCA.com/OU=intermediateCA3verify
error:num=20:unable to get local issuer certificate' - I'm presuming
that OpenSSL isn't keychain aware and that is normal behaviour.

 

[Pete Shaw]

One last thing to add is that I have been careful throughout to make
sure I did not have duplicate certs when trying in different locations
i would always clean up the ones in other locations. .

There also does not seem to be anything related reported in the system
logs or console.

 

[Nathan Herring [MSFT]]

Consider the bug filed.

Just to make sure, does your server certificate has a subject alternative
name field? Is the FQDN of the server (which is probably in the common name
field) not duplicated there?

-nh

 

[Pete Shaw]

Nathan,

Our certs do not have subject alternative name field. The our standard
for the commmon name field is the FQDN of the server.

If it helps contact me off list and can give you our company details
etc, or if you want further troubleshooting info reports (which with
company specific info I can't post publically).

cheers

Pete

 

[Pete Shaw]

Just to have an answer for people for searching for a fix to this
issue, after working through with Nathan.

The issue is that when reading a SSl certificate it will ignore the
common name if the subjectAltName key extension exists, and thus if
there was a match in the common name but no elements (or unmatching
elements) of the subjectAltName, Entourage will report a certificate
problem (and moreover, the wrong certificate problem, that the root
certificate was wrong).

Once we had a certificate recreated without the subjectAltName key it
resolved the issue.

 

[Auction]

How do you check the certificate for the SubjectAltName and how do you
correct it, I understand that the common name and SubjectAltName need to
match.

Perry Cadman

 

[Nathan Herring [MSFT]]

If it's an Exchange server, or if it also supports some kind of web
functionality, connect to it via https://mail.whatever.com or as
https://websitename via Safari. In Safari, you should get a little lock icon
in the upper right hand corner. If you click the lock icon, you will get the
certificate chain used to verify the server. The bottom-most one is the
server's certificate. It should be selected by default.

Expand the Details section. Scroll down and it should list various
Extensions (which usually, but not always exist). The extension you want to
look for is "Subject Alternative Name ( 2 5 29 17 )". (The numbers are the
OID for subjectAltName.)

That said, we'll be addressing this and other certificate issues in a
forthcoming release.

-nh