Tag: Certificate

Nokia E7 not working with Issuance Policies

Posted on by

When using a Nokia E7 to synchronize with your Exchange server you might get into trouble if your certificates contains the Issuance Policies (Certificate Policies) extension.

Sniffing the traffic I found that when trying to connect the Nokia device sent an TLS Layer-1 Encrypted Alert (Hex 02 0A) and killed the TLS negotiation. Initially I was pretty sure I made some mistake when I installed my root CA certificate in the device, but after double-checking that, I was still unable to get the TLS handshake to work.

After a few hours of troubleshooting I found that the problem was that the certificate I used on my Exchange CAS server had an Issuance Policy referring to my CPS. In order for the Nokia E7 device to be able to consume any of my internal https sites I needed to change the certificate template and remove the Issuance Policy extension and renew my certificates used by my Exchange CAS and other internal websites.

After that the Nokia E7 was able to synchronize and access other internal https sites.

ISA 2006 and SAN Certificates

Posted on by

Many customers and others have been confused by the well spread rumor that ISA 2006 do not support SAN certificates like the ones used by Exchange 2007.

The confusion is often caused by the fact that they do not understand how ISA is using SSL bridging in a typical Exchange Publishing scenario.

You have to remember that SSL bridging means that there are TWO (2) separate SSL sessions going on.

Session 1: From the Client (usually on the Internet) to ISA
In this case the certificate shown by ISA is validated by the client and must satisfy the demands the client has, if no warning is to appear. If the client supports SAN certificates then you can have a SAN certificate in the ISA listener.

Session 2: From ISA to the published server (usually on the Internal network)
In this case the certificate shown by the published server needs to satisfy ISA (the original client has nothing to do with this). This means it has to be issued by a trusted CA and have a Common Name that matches the hostname on the “To” tab in the publishing rule. If this is a SAN certificate, the first SAN also needs to be the same name as the name used on the “To” tab in the publishing rule.

To summarize, ISA 2006 do support SAN certificates, but when acting as a client it can only validate the common name and the first SAN entry. This will change in SP1 (released later this summer), with SP1 ISA will as a client be able to validate any SAN entry to match the “To” used in the publishing rule.

The “great” Jim Harrison, has described this in more detail in his blog at http://blogs.technet.com/isablog/archive/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing.aspx

Verisign och ActiveSync

Posted on by

De flesta väljer att köpa ett certifikat från t.ex. Verisign när man börjar prata om att köra ActiveSync.

Tanken är att man inte ska få några problem med att telefonen inte “litar” på certifikatet.
Döm om förvåning när det visar sig att man kan få samma problem även med ett köpt certifikat!

Detta kan inträffa om man t.ex. köper ett certifikat utfärdat att “VeriSign Class 3 Secure Server CA”, detta är nämligen en s.k. intermediate CA och har en RootCA som heter “VeriSign Class 3 Public Primary CA”

Root CA”n finns i Mobile 5 som trusted men inte den intermediate som utfärdat den.
Detta gör att Mobile 5 kan uppfatta certifikatet som icke trusted.

Om man ska publicera ActiveSync i ISA och har ett sådant certifikat (kan tänka mig att det gäller för fler som använder intermediate CA) MÅSTE man i ISA lägga in “VeriSign Class 3 Secure Server CA” som en Intermediate CA i samband med att man imorterar certifikatet.

När man exporterar Certifikatet från den IIS där man gjorde requesten bockar man lämpligen i att ta med alla certifikat i pathen så får man med sig både intermediate certifikatet och rootcertifikatet att installera på ISA”n.

ISA kan nu ge Mobile 5 “hela” pathen för certifikatet och telefonen kan se att den kommer från en “trusted” root CA.