codesalot.com

If you want to use HTTPS (without the annoying browser certificate warnings) or MTLS with a Codian MCU, you’ll need to install a certificate on the MCU.

Remember that you’ll need the “Encryption” release key to enable SSL in any form. This is a free key that kan be ordered from TAC.

Under Network -> SSL certificates, you’ll find this screen:

So we need to provide a certificate and a private key corresponding to the certificate, which means that we need to create a CSR and import both the key and the certificate to the MCU.

I’ll show how to do this using openSSL and a Windows CA. If there is an OCS/Lync implementation in the environment, you could use the wizard to create the cert, but you would have to split it up with something like openSSL afterwords anyway, so the easiest thing is just to create it all with openSSL.

openSSL can be found for almost any platform, I use openSSL for win32 

Create the CSR

Use this command to create the CSR

openssl req -new -newkey rsa:2048 -nodes -out <name_of_the_cert>.csr -keyout <name_of_the_key_file>.key -
subj "/C=<countrycode>/ST=<state>/L=<City>/O=<Organisation>/OU=<Organisational Unit>/CN=<fqdn.of.mcu>"

Exchange all the <variables> with the correct values.

This should create two files, <name_of_the_cert>.csr and <name_of_the_key_file>.key and place them in the same directory as you run the command.

Create the cert

Copy the .csr file to the CA. In a cmd window, navigate to the folder you copied the .csr to and run:

certreq -submit -attrib "CertificateTemplate: WebServer" <name_of_the_cert>.csr

If the CA is configured to issue certs automagiacally, you should have be asked where to save the .cer. If not, you’ll have to open the CA MMC snapin and issue the cert manually.

Add the cert to the MCU

Back on the MCU, browse to the .cer in the Certificate field and the .key in the Private Key field. Leave the password field empty. Restart the MCU and you should be good to go.

Creating a trust store

The trust store to be uploaded needs to be in .pem format. Export the root certificate you need to trust to a DER encoded file. (normally .cer) and run the following command:

openssl x509 -inform der -in <rootcert>.cer -out <rootcert>.pem

<rootcert>.pem can be uploaded as the trust store. 

I had a weird problem with an 2007R2 installation last week. The addressbook had stopped working. I checked all the normal errors, certificates and IIS on the FE, but everything seemed to be just fine. The addressbook files were created, and I could download all files in the browser. Everything seemed to be normal, except that the clients were giving the error about not being able to download the addressbook.

After a bit of searching the internets, I came across this. Seems that there was some new functionality added to IE8 where it refuses the certificate if the CRL is unreachable.

The solution is either to fix the CRL, or to uncheck “Check for server certificate revocation” under advanced settings in >IE8.

I recently was installing OCS in a domain where we for some reason could not use an enterprise CA, so a standalone was installed. This works fine on the MOC clients, but it was a problem when we were trying to use Communicator Phone Edition.

According to the phone ed. deployment guide, the CPE gets the certificate from AD like this:

1.   The device searches for Active Directory directory objects of category certificationAuthority. If the search returns any objects, the device will use the attribute caCertificate. This attribute is assumed to hold the certificate and the device will install the certificate.

The Root CA certificate must be published in the caCertificate for Communicator Phone Edition. To place the Root CA certificate in the caCertificate attribute, use the following command:

certutil -f -dspublish <Root CA certificate in .cer file> RootCA.

2.   If the search for Active Directory objects of category CertificationAuthority does not return any objects, or if the objects have empty caCertificate attributes, the device searches for Active Directory objects of category pKIEnrollmentService in the configuration naming context. Such objects exist if certificate AutoEnrollment was enabled in Active Directory. If the search returns any objects, it will use the dNSHostName attribute returned to reference the CA and it will then use the Web interface of the Microsoft Certificates Service to retrieve the Root CA certificate by using the HTTP GET command http://<dNSHostname>/certsrv/certnew.p7b?ReqID=CACert&Renewal=-1&Enc=b64.

If neither of these methods succeeds, the device displays the error message “Cannot validate server certificate” and the user is unable to use the device.

The certutil command described above requires you to have necessary rights in the forest, which we didn’t have.

The solution ended up being:

* Run the server 2k3 reskit tool pkiview.msc
* Right click Enterprise PKI and choose Manage AD Containers
* In the NTAuthCertificates tab, add the root certificate of the standalone CA

That should be it! When we did this the phones started downloading the right certificate.

Edit: This might not be working perfectly. Some phones use an extreme amount of time downloading the right certificate. Might be the messy PKI in the forest being the problem, but i will need to test this some more…