Automatic Root Certificates Update Insanity

I have no doubt that Microsoft was trying to solve a big problem when they came up with the Automatic Root Certificates Update solution. Ideally, with Automatic Root Certificates Update a PC/Server can keep the list of Root Certificate Authorities up to date on demand. Also, Automatic Root Certificate Update would allow for the addition of other Root Certificate Authorities that may not have been approved when the OS was first released.
Unfortunately, I have found that the Automatic Root Certificate Update solution creates some problems when there are customized properties on Trusted Root Certificates.

As an example, the proper installation of GoDaddy Intermediate Certificates requires the disabling or deletion of an existing Trusted Root Certificate.

NOTE: If the Go Daddy Class 2 Certification Authority root certificate is currently installed on your machine you will need to disable it from the Trusted Root Certification Authorities folder.

So now you have a properly installed GoDaddy certificate, right? You won't for long.

At some point in the future the server will query Windows Update and realize that the disabled GoDaddy certificate is no longer enabled and it will update the certificate and re-enable it. There will be an Event Viewer message from the source of CAPI2.

A simple update of the Trusted Root certificate will not break your server software component that has that certificate assigned. The services will have to be restarted. Which means, at some point in the future when someone reboots the server suddenly things do not work and you have no idea why. This has been observed with both Lync Edge servers and Front End servers that were using GoDaddy certificates. Now that is fun.

So... yes we can disable Automatic Root Certificate Update, but there is a downside I've noticed. Much like on Windows Server 2003, we now have to download and install Trusted Root Certificates manually that are not part of the original OS.

Now you are thinking I will never go with GoDaddy certificate because of this. Guess what, I've personally seen an issue with Digicert and I've seen mention of Entrust based certificates also having issues with Automatic Root Certificate Update.
So... I don't have any really great answers for making this a non-issue at this point. If you do, please send me an email or send me a message on twitter.

Here is the procedure to disable Automatic Root Certificate Update.

Turn off Automatic Root Certificates Update

To perform this procedure, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.

To turn off Automatic Root Certificates Update:

 Click Start, and then click Run. 

1. Type gpedit.msc and then click OK.
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
3. Double-click Administrative Templates, double-click System, double-click Internet Communication Management and then click Internet Communication settings.
4. Double-click Turn off Automatic Root Certificates Update, click Enabled and then click OK.
5. Close the Local Group Policy Editor.

The Days of the Telephone Number are Dwindling

Dialing a number to reach a person or business will become the exception, rather than the rule.

Today if you wanted to reach Microsoft Sales by phone you would need to dial (800) 642-7676.

But, would it not be easier to remember sales@microsoft.com?

I came to this realization back in 2003 when I started working with SIP based Unified Communications products from Nortel.

That Nortel product had a number configured for a user, but the phone number was not required. A call could be placed to another person if you had their SIP URI (john@example.com). The number for the most part was so they could interact with the PSTN.

They had both PBX and Carrier version of their SIP product that were intended to work together to provide SIP trunking and Federation with other organizations. Some thought this vision was a bit early for the market to really understand the value, but Nortel also did not evangelize the vision. 

Fast forward a few years and now we have Unified Communications well evangelized from multiple vendors. Nortel lost the opportunity that came with being early to market with a revolutionary product idea.

Now others, like Microsoft can capitalize on those ideas and add their own. 

For years, Microsoft, has provided an efficient way to connect organizations together that use Microsoft based Unified Communications. These organizations can communicate seamlessly across the Public Internet without any VPN. This is done through the Edge Server role in Office Communications Server and now Lync Server 2010.

No PSTN involved.

No big SIP server in the sky.

No dialing of a phone number.

It is all simply done through the existing DNS system by calling a users SIP URI (john@example.com).

Much like an email address the SIP URI contains all the information needed to route the call to an organization (example.com) and which user or endpoint should receive the call once we reach that organization (john).

So today, if you use a Microsoft based Unified Communications system and communicate with partner organizations or vendors usig the Edge Server role you could potentially make a call to a SIP URI like sales@microsoft.com and have that reach a real person. Again...

No PSTN involved.

No big SIP server in the sky.

No dialing of a phone number.

But, what hasn't happened yet, is a way to fully Federate (IM, Presence, Voice, Video, Desktop Sharing etc.) between all the disparate UC/Communications systems.

Recently, Microsoft has made a historic acquisition of Skype. Microsoft, in one move, has the pieces to become a SIP trunking provider, but more importantly they now have the ability to provide Federation to other organizations that are not using Microsoft Unified Communications.

Consider this...

Work has been done on a Avaya solution to connect to Skype.

Although the agreement has not been renewed, work was also done with Asterisk. The agreement possibly lapsed because both Microsoft and Asterisk wanted to revisit the relationship and possibly might leverage the Skype for SIP interface instead. Just a theory of mine at this point.

With the Skype for SIP interface, what is to stop Microsoft from making it interoperate with ANY communication system? If a communications system doesn't support SIP then a PRI SIP Gateway can be used.

Skype for SIP already supports the following PBX systems:

• 3CX
• Avaya
• Cisco
• Freetalk
• Grandstream
• LG Ericsson
• NEC
• ShoreTel
• Siemens
• SIPfoundry

and the following PRI SIP Gateways:

• Audiocodes
• Grandstream
• Net
• VoSKY

So, now ponder these final thoughts...

Disparate systems all talking SIP can connect to Skype and no longer have to make a connection through the PSTN.

The only real need for a phone number with this scenario is to provide backwards compatibility with the PSTN.

Dialing a number to reach a person or business will become the exception, rather than the rule.

SSL Cipher Order strikes again

Issue:

Lync Server 2010 would intermittently fail to communicate with AOL AIM clients via PIC.

But wait...

That's not all... At the same time I also noticed the edge failing to negotiate TLS with Federated Partners that had Entrust certificates (may affect other CAs, but I noticed Entrust in my eventlog)

Note that this would only be reproduciable if your Lync/OCS 2007 R2 Edge role is running Windows Server 2008 (x64) or Windows Server 2008 R2 (x64); not Windows Server 2003 (x64).

Resolution:

Modify the SSL cipher order so that the OCS/Lync Edge role will initially establish the SSL dialog using the TLS_RSA_WITH_RC4_128_MD5 cipher suite.

In order to change the cipher suite order, do the following on your Windows Server 2008 (x64) or Windows Server 2008 R2 Edge server (if the edge server is joined to a DMZ domain then the Group Policy on the Domain Contorller will need to be modified instead of the local machine):

1. Start -> Run -> regedit.exe -> OK
2. Within the Registry Editor, locate the following Key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

3. Right-click the key and select "Export"
4. Select the Desktop and type in an a filename to export the registry key to.
5. Right-click the file on the desktop and select “Edit”
6. The contents of the file should look like this if you have not set the cipher suite order yet:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]

7. If you have set the cipher suite order before then there may be a value for the key that looks similar to this:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]
"Functions"="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_MD5,TLS_RSA_WITH_NULL_SHA"

(Note there may be some truncation at the end because Group Policy Editor has a limit of 1023 characters) Thanks to Alex Lewis for pointing this out.

8. The goal is to move TLS_RSA_WITH_RC4_128_MD5 to be at the front of the list. So, in your exported registry key file, find TLS_RSA_WITH_RC4_128_MD5, cut it, navigate to the beginning of your long SSL cipher string, and paste TLS_RSA_WITH_RC4_128_MD5.. (Note: if your string was truncated before you might want to use the example below instead) The new order should look like the following:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]
"Functions"="TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_MD5,TLS_RSA_WITH_NULL_SHA"

9. Check the string for accuracy and make sure there are no line breaks within the SSL cipher string.
10. Save the file and then double-click the file to merge the changes with your current Registry.
11. To verify, in the Registry Editor, navigate to
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]
12. For the changes to take effect, restart your Windows Server.

Another way to do this is also via PowerShell take a look at this site for an example (Thanks to John A Cook for sending this along):

http://derek858.blogspot.com/2010/06/powershell-command-to-change-windows.html