Root Certificate

K

Kevin Ledgister

I've tried the Mac Help Desk instructions but I still get the same root
certificate is not installed issue and Entourage won't connect to Exchange.

Our IT admin created a *.crt certificate from the Exchange server but it has
a host name mismatch.

Would a host name mismatch in the certificate terminally affect Entourage to
connect to Exchange 2003?
 
C

Chris Ridd

I've tried the Mac Help Desk instructions but I still get the same root
certificate is not installed issue and Entourage won't connect to Exchange.

Our IT admin created a *.crt certificate from the Exchange server but it has
a host name mismatch.

Would a host name mismatch in the certificate terminally affect Entourage to
connect to Exchange 2003?
Click to expand...

Using SSL *requires* that the name the client uses to contact the server
exactly matches the name in the server's certificate.

If your "IT admin" has screwed up this basic stuff, just tell Entourage to
contact the broken name, and then hardwire this broken name in your
/etc/hosts file.

In more detail:

Say you are currently talking to "exchange.example.com" and your "IT admin"
has used the name "broken-name.microsoft.com" in the certificate.

1) Use the Lookup tab in Network Utility.app to find the IP address for
exchange.example.com. Say it returns 1.2.3.4...

2) In Terminal.app, type:

sudo -s
echo "1.2.3.4 broken-name.microsoft.com" >> /etc/hosts
exit

3) Restart Entourage.

Cheers,

Chris
 
N

Nathan Herring [MSFT]

More specifically, the rules are that:
1) You must match the common name in the subject name <OR> you must match a
FQDN or IP address found in a subject alternative name extension.
2) If you have a critical Extended Key Usage ( 2 5 29 37 ) extension, then
it must list Server Authentication ( 1 3 6 1 5 5 7 3 1 ) as one of its
purposes.

Given that, we don't have support for comparing IP addresses in subject
alternative names. (Yet.) We also have some issues about reporting what kind
of certificate error it was.

We have a few issues with parsing some certificates and verifying these
rules that have been corrected and will be available in an upcoming release.

I highly suggest taking up the issue with your IT administrator. They should
be issuing correct certificates. They can use the "*.foo.com" syntax to be
able to match all the hosts in the foo.com domain (though not "a.b.foo.com",
for which it would need "*.*.foo.com").

-nh
 
C

Chris Ridd

More specifically, the rules are that:
1) You must match the common name in the subject name <OR> you must match a
FQDN or IP address found in a subject alternative name extension.
2) If you have a critical Extended Key Usage ( 2 5 29 37 ) extension, then
it must list Server Authentication ( 1 3 6 1 5 5 7 3 1 ) as one of its
purposes.

Given that, we don't have support for comparing IP addresses in subject
alternative names. (Yet.) We also have some issues about reporting what kind
Click to expand...

I thought the job of comparing the name the user entered to connect to with
the name in the server's cert was the job of Apple's security framework?
Apple's tpPolicies.cpp seems to have all this functionality...

<http://darwinsource.opendarwin.org/10.4.4.ppc/libsecurity_apple_x509_tp-248
18/lib/tpPolicies.cpp>

(It looks broadly similar to the code in 10.3.)
I highly suggest taking up the issue with your IT administrator. They should
be issuing correct certificates. They can use the "*.foo.com" syntax to be
able to match all the hosts in the foo.com domain (though not "a.b.foo.com",
for which it would need "*.*.foo.com").
Click to expand...

You're right - working around the error shouldn't be necessary.

But experience suggests that an "IT admin" thinks it works with Windows
clients they won't be keen to do anything to make it work with anything else
:-(

Cheers,

Chris
 
N

Nathan Herring [MSFT]

I thought the job of comparing the name the user entered to connect to with
the name in the server's cert was the job of Apple's security framework?
Apple's tpPolicies.cpp seems to have all this functionality...

<http://darwinsource.opendarwin.org/10.4.4.ppc/libsecurity_apple_x509_tp-248
18/lib/tpPolicies.cpp>

(It looks broadly similar to the code in 10.3.)
Click to expand...

Yes, Apple has code to do this. We wrote our own implementation back when it
was not obvious that Apple was going to provide one. Sadly, they released
their support about the same time as we did ours, so...
You're right - working around the error shouldn't be necessary.

But experience suggests that an "IT admin" thinks it works with Windows
clients they won't be keen to do anything to make it work with anything else
:-(
Click to expand...

That said, most of these SSL issues are reproducable in Windows
environments. You should be able to issue an https://subdomain.domain.com in
WinIE 6 and get a similar error when the cert only supports "domain.com". If
it gives an SSL error in WinIE (and/or Safari) and not in Entourage, or vice
versa, it's probably a bug, and should be reported. (At this time, we know
of a small number of such issues.)

I play this It-doesn't-work-on-Windows card a lot at work. As you might
imagine, our IT folks are significantly more interested in supporting
Windows, even when it's theoretically an issue with a platform-neutral
technology such as SSL.

-nh
 
K

Kevin Ledgister

I checked out our issuer's certificate and the common name listed in the
Subject Name and Issuer Name is different and we don't have Subject
Alternative Name.

Is it the fact that the common name is different why I am experiencing these
problems?

Is there anything I can do on the client end to fix this? My IT dept. is
swamped and they promised to look at it but couldn't guarantee a fix.

Are the updates to Entourage to fix some of these issues coming in an update
or a whole new release?
 
C

Chris Ridd

I checked out our issuer's certificate and the common name listed in the
Subject Name and Issuer Name is different and we don't have Subject
Alternative Name.

Is it the fact that the common name is different why I am experiencing these
problems?

Is there anything I can do on the client end to fix this? My IT dept. is
swamped and they promised to look at it but couldn't guarantee a fix.
Click to expand...

Hacking the name in the certificate's actual subject into /etc/hosts is
about the only way, I reckon.

Cheers,

Chris
 
C

Chris Ridd

Yes, Apple has code to do this. We wrote our own implementation back when it
was not obvious that Apple was going to provide one. Sadly, they released
their support about the same time as we did ours, so...
Click to expand...

Doh! Oh well, I guess it is always nice to be able to delete code and rely
on the OS from time to time ;-)

Cheers,

Chris
 
K

Kevin Ledgister

Hacking the name in the certificate's actual subject into /etc/hosts is
about the only way, I reckon.

Cheers,

Chris
Click to expand...

Actually your suggestion to modify the /etc/hosts file helped me to connect
to our ldap server and use our exchange server name instead of the IP
address. Didn't solve the SSL issue but I greatly appreciate each step
forward.

Thanks!

Kevin
 
N

Nathan Herring [MSFT]

I checked out our issuer's certificate and the common name listed in the
Subject Name and Issuer Name is different and we don't have Subject
Alternative Name.

Is it the fact that the common name is different why I am experiencing these
problems?
Correct.

Is there anything I can do on the client end to fix this? My IT dept. is
swamped and they promised to look at it but couldn't guarantee a fix.
Click to expand...

I haven't validated it, but I believe there was a previous post by Chris
Ridd which may do the trick.
Are the updates to Entourage to fix some of these issues coming in an update
or a whole new release?
Click to expand...

The updates will not fix your issue -- Entourage is operating by design with
regard to your issue. All but one of the fixes are coming in an update.

-nh
 
K

Kevin Ledgister

I haven't validated it, but I believe there was a previous post by Chris
Ridd which may do the trick.


The updates will not fix your issue -- Entourage is operating by design with
regard to your issue. All but one of the fixes are coming in an update.

-nh
Click to expand...

I tried Chris Ridd's suggestion but it didn't work for Exchange (but it
helped for ldap).

In my example, the common names of the certificate do not match and neither
of the common names are the same as the server name used in the OWA URL.
(For example, the common name is EXCH1234 and MCWEB but the OWA URL is
https://webmail.mycompany.com/exchange).

Should the common name be webmail.mycompany.com and must both common names
match?

Sorry to be a pain on this but I want to inform our IT department with
precise information.
 
N

Nathan Herring [MSFT]

I tried Chris Ridd's suggestion but it didn't work for Exchange (but it
helped for ldap).

In my example, the common names of the certificate do not match and neither
of the common names are the same as the server name used in the OWA URL.
(For example, the common name is EXCH1234 and MCWEB but the OWA URL is
https://webmail.mycompany.com/exchange).

Should the common name be webmail.mycompany.com and must both common names
match?
Click to expand...

The common name should be specific to the server. I would suggest that the
common name remain "EXCH1234.fully.qualified.domain.name" and you add a
subject alternative name extension with a FQDN entries of
"EXCH1234.fully.qualified.domain.name" and "webmail.mycompany.com" -- the
duplication is just for explicitness, that the common name really is a FQDN
and not some other random name. That way, every server can have its own
certificate, but all of them with the subjectAltName extension can support
accesses via the OWA URL as well.

I'd also suggest using an IP address of the server in the subject
alternative name (so long as it's an actual internet IP address statically
assigned to the machine), but Entourage's SSL code doesn't do subjectAltName
IP matching in the current release, and there's actually a bug (which will
be addressed in an upcoming update) which causes certificates with an IP
address subjectAlternativeName entry to be mis-parsed, considered to be
badly formed, and thus treated as untrusted. As it is, I'd hold off until
the update, and even then, you still won't be able to securely connect to
the server by IP address.

Unfortunately, the stock installation of Microsoft certificate server
doesn't allow you to create certificates with a subject alternative name. If
you're using it to generate the certificates, you have to tweak some
settings first. I found a summary of how to do it here for LDAP (though it's
identical for your purpose):
<http://guy.netguru.co.il/categories/6-Security>. The steps use a lot of
information from
<http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies
/security/advcert.mspx> which is more of a reference than a How-To.

If they're using certtool, I don't think it'll be able to generate the
request -- they'll have to use openssl req (or just req(1)), though I'm not
quite sure how to specify the additional subject alternative name item.
Sorry to be a pain on this but I want to inform our IT department with
precise information.
Click to expand...

Understandable.

-nh
 
N

Nathan Herring [MSFT]

S/MIME and SSL, while both using certificates, use them in slightly
different ways and have slightly different requirements. Unfortunately, none
of the items in this resource look like they are relevant for generating an
SSL certificate for the Exchange server, though clearly Thawte or Verisign
could be the companies responsible for producing a SSL certificate. They'll
each have different mechanisms for creating/submitting a certificate
request, though if you can generate the correct CSR via req(1) or
certutil.exe, you can probably get them to take it directly and issue a
certificate based on it.

-nh
 
Top