Windows PKI SHA-1 to SHA-2

(How do you hear me now?)

Thanks go to fellow CDW co-workers Dean Sesko, Russell Despain, and Keith Crosby

 

What is the issue here?

Basically, the issue is that SHA-1 for PKI is going away in favor of SHA-2, and you WILL have customers that need help with this.

 

Reference:

• https://www.networking4all.com/en/ssl+certificates/ssl+news/transitioning+from+sha1+to+sha2/
• http://blogs.technet.com/b/askds/archive/2015/04/01/migrating-your-certification-authority-hashing-algorithm-from-sha1-to-sha2.aspx
• https://technet.microsoft.com/en-us/library/cc751157.aspx
• http://www.entrust.com/sha-1-deprecation-on-to-sha-2/
• http://security.stackexchange.com/questions/73491/how-will-sha1-deprecation-affect-sha1-roots-in-os-browser-trust-stores
• https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
• https://www.digicert.com/sha-2-ssl-certificates.htm

 

AND…?

Any Microsoft supported operating system, properly patched/upgraded, and any Microsoft supported application, again properly patched/upgraded, will support SHA-2 PKI certificates.

 

Reference:

• http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

…there are some caveats: notably around XP and Server 2003, and oddly, Server 2008.

Reference:

• https://support.microsoft.com/en-us/kb/968730
• https://support.microsoft.com/en-us/kb/938397

So, there is not an issue with Microsoft supported products; the issue is with BYOD and Microsoft making a HUGE effort to support alternative browsers and operating systems. And those browsers and operating systems are fixing on deprecating their support of SHA-1.

 

Reference:

• https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
• http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
• http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

However, there are going to be numerous AD internal CA’s out there that are issuing SHA-1 certificates, and depending on how the environment is configured, the customer will need to renew their application certificates for internal use. Logically, it makes sense that the desirable outcome of renewing the application certificates is that the issuing PKI be SHA-2.

CDW AD resident experts advise instantiating a new Root CA, and if needed, a new subordinate CA for issuing SHA-2 certificates. But, you know those pesky customers, they may not want to do this. Which would call for modifying the existing structure to hand out SHA-2 vice SHA-1.

 

Reference:

• https://technet.microsoft.com/en-us/library/dn771627.aspx

Experimentation over the last several hours has revealed the following:

• Migrating the existing SHA-1 CA went just fine.
• The new SHA-2 Root Certificates updated almost immediately into the Trusted Root

• I was able to request new SfB certificates and they were issued by the CA based on the new 3DES/SHA-2 root
  • However, the host server was not able to chain them up into the Trusted Root.
  • I rebooted.
  • I ran GPUpdate –force
  • I rebooted.
• After waiting overnight, THEN the new certs chained up properly. Why this delay in chaining to the new Root I have no idea. I suggest that if you do this for real, that you do the work on one day and then plan on waiting for at least 8 hours before attempting to get new certificates and expecting them to chain up to the new root.

Testing:

After updating the internal certificates on my SfBSE to a new SHA-2 I successfully tested

• using Win8.1 and Win7sp1
  • IE 11
  • Chrome Version 43.0.2357.134
• Surface Pro 2 (8.1) IE
• iPad (iOS 8.0.2) Safari

Firefox 39 fails – due to it not liking the root cert – why is FF so blinking difficult? Why does it have to have its’ own key chain? The O/S has the root cert! It does this same shit when installed on *nix. After manually importing my new root cert, it worked just fine.

• SIP Phones.  I had to restart services (stop-cswindowsservice start-cswindowsservice) AFTER I changed the certificate to the new SHA-2 certificate before my AudioCodes 420HD and Polycom VVX-600 would log in.  Why, I do not know.

 

The SfB/Lync Connection!

You may have been wondering why *I* am worried about this.  Well, on literally every project with which I have been involved over the last few years, they all had *nix and Mac workstations, along with loads of iPhones, iPads, *nix tablets, droids, surface tablets, and here and there the odd Windows phone.  And, you have to know that, in most cases, all of these were attached to an internal corporate wireless.  And in some cases, the internal wireless was dropping these devices into the production network, which put them in a position to being able to directly contact Lync/SfB resources on internal servers, that, for the most part, had a PKI certificate from an internal CA.  With SHA-1.  You knew it had to be simple, right?

Any input to solving/addressing the observed delay would be most welcome. I, for one, totally expected to have the new certificate chain immediately – the appropriate root cert was in place!

YMMV

DHCP option 002 for Lync phones

Maybe I have been living under a rock… but I have been doing this manually… finally found a nifty chart so I can stick it in OneNote instead of having to figure it out each time – complete with instructions on how to calculate manually.  I take no credit, this is blatantly cut from a Cisco website source.

Standard Pacific time is GMT -8. This is a simpler way to calculate GMT with negative values:

1. The number of seconds equivalent to - 8 hours = - 8 hours * (3600 seconds / hr) = - 28800 seconds.

2. With a scientific calculator, enter the number -28800 in the calculator with decimal values. The (-) sign is very important. In order to get the negative sign in front, press the +/- key.

3. Choose Hex. This gives you FFFFFFFFFFFF8F80. This is because, by default, the calculator has Qword enabled.

4. In order to get rid of the extra Fs, choose Dword. This produces the value FFFF8F80. If you do not have this option in your calculator, use only the first eight digits from right to left.

5. The value placed in the DHCP pool configuration now becomes option 2 hex FFFF.8F80.

 

Table of Conversion of Different Offset Times into Hexadecimal

This table gives the conversion of the different time zones around the world. The hexadecimal values are set to have a fixed length of 32 bits as specified in Option 2 of the DHCP RFC 2132. For a world timezone map, refer to World Time Zone Map.

GMT offset (in hr)	GMT offset in seconds	GMT offset in Hexadecimal
0	0	0000.0000
+1	3600	0000.0E10
+2	7200	0000.1C20
+3	10800	0000.2A30
+4	14400	0000.3840
+5	18000	0000.4650
+6	21600	0000.5460
+7	25200	0000.6270
+8	28800	0000.7080
+9	32400	0000.7E90
+10	36000	0000.8CA0
+11	39600	0000.9AB0
+12	43200	0000.A8CD
-1	-3600	FFFF.F1F0
-2	-7200	FFFF.E3E0
-3	-10800	FFFF.D5D0
-4	-14400	FFFF.C7CD
-5	-18000	FFFF.B9B0
-6	-21600	FFFF.ABA0
-7	-25200	FFFF.9D90
-8	-28800	FFFF.8F80
-9	-32400	FFFF.8170
-10	-36000	FFFF.7360
-11	-39600	FFFF.6550

Example

Pacific Time Zone = GMT –8

60*60*8 = 28800.  Change sign. Now we have –28800.

Click the Hex button.  Now we have

Click the DWord button.  Now we have

Here is the value in the DHCP Server Options. Note that we take the DWord value and append “0x” to it.

YMMV

Maximum Number of names in a SAN Extension

In what is sure to be a long standing record (of sorts) for me (and maybe only me) – I just submitted a CSR to a public provider with 53 domains in the SAN field.  This raised the question:  “how many entries or names can be in that one field?”  I know there has to be some sort of limit. 

Handy Dandy, we had a TMG guy in the room, so we asked him.  While he did not know off the top of his head, he did have an answer in mere minutes (where I had googled for about 10 and found squat).

http://social.technet.microsoft.com/wiki/contents/articles/3306.aspx

So, now we know the field is defined by a database, that a Windows PKI CA is limited to 4k of names, and that somewhere around 150 25 character domain names eat up just under 4k.  By extension, we can assume (and we know what that means) that the Public cert providers are following the same RFC and that they will have a similar limit.

How about that?  An answer to a question you did not know you had!

YMMV

Oh my aching brain cell, or, dcpromo u gotta be kidding me!

 

Stupidly, I attempted to join a new 2008 R2 DC to our domain the other day.  I was doing it from a different site, but heck, should be no sweat, right?

Wrong.

DNS was good, name resolution worked, and the machine could join the domain, but why the dcpromo errors?

“failed to examine the active directory forest.  the error was: the operation cannot conitnue because the ldap connect/bind operation failed: error: 58” 

and

“the operation cannot continue because ldap connect/bind operation failed: error: 1326”

I tried various fixes and whatnots…and then stumbled across a little tidbit here that implied that the computer administrator (pre-domain) password might need to match the forest root domain administrator password. 

Having exhausted all my other possibilities, I tried this - and did not expect any success.

But, WTFO!  It worked.  So now the question is, why?

Users unable to join LM session, MEET NOW button not working, LM functions grayed out.

In the middle of a deployment - an OCS R1 to R2 migration - we noticed that the LM functions were not working.  LM worked for the individual workstations when connecting to a remote session initiated by a federated partner.  The meeting policy at the global level was created, edited, and assigned correctly.

We noticed that we had neglected to run the Web Conferencing validation tests.  We had a tick box on our checklist, we had just overlooked it.  Running the validation wizard revealed that the validation connection checks were failing to successfully contact the MCU on either of the Front End servers.  We double-checked everything, and concluded that everything on the OCS side was correct.

“Aha,” says we.  “Must be a certificate issue.”  Except that we were using good public certificates on all the interfaces for the FE servers.  Bummer.  Except, I then read this blog article.

Oddly, this was so on target it floored me.  I used the solution that changed the usage on the Trusted Root Certificate to “ALL” - voila!  problem resolved.  I don’t know who exactly wrote this, and what follows is a cut ‘n paste and edit of the relevant parts of that blog that fixed my issue. Many thanks to the unknown CSS engineer (Dave) who took the time to write this up.

Event Type:    Error
Event Source:    OCS MCU Infrastructure
Event ID:    61013
User:        N/A
Computer:    OCS1
Description:
The process DataMCUSvc(2596) failed to send health notifications to the MCU factory at https://OCS1.contoso.com:444/LiveServer/MCUFactory/.
Failure occurrences: 3491, since 3/24/2009 10:05:18 PM.

If you run the Web Conferencing validation wizard from the OCS Pool, you may find the following error in the output log:

MCU Type: meeting
URL: https://OCS1.contoso.com:444/LiveServer/MCUFactory/
HTTP Connectivity Error : ReceiveFailure
HTTP Connectivity Error : Receive failure typically indicates that the connection was closed by
the remote host. This can happen if the remote server does not trust the certificate presented by the
Local Server.

HTTP Connectivity Error : Ensure that the certificate of the local server and remote server are both
valid, have not expired, and contain valid subject name. In addition, ensure that the certificate chain
of both Server(s) are valid. Ensure that the certificate chain of the local server is installed
on the remote server and vice-versa. The most up-to date certificate chain that was used to issue
the server certificate must be present.

When you see errors like these, it usually indicates that a certificate-related authentication problem exists with the OCS Pool (or with a particular OCS Front End server).  Most of the time, this turns out to be a problem with the certificate from an issuing Certification Authority.  To troubleshoot this issue, you would typically perform the following steps:

1. Log in to the affected OCS 2007 Front End server either locally or remotely using Remote Desktops.
2. If the issuing CA is a Root CA (the top of the list), expand Trusted Root Certification Authorities > Certificates
1. If the issuing CA is an Intermediate CA (not the top of the list), expand Intermediate Certification Authorities > Certificates
2. From the list of CA certificates, right click on the certificate and choose Properties
3. Under the General tab, verify that Enable all purposes for this certificate is selected (or, if Enable only the following purposes is selected, verify that both Server Authentication and Client Authentication are enabled)
4. Click OK to close the properties of the CA certificate.
5. If this was an Intermediate CA certificate, repeat steps 6 through 10 until these settings from all certificates in the trusted certification chain are verified
6. Close the Certificates Management Console (be sure to restart services if you made any changes)

Why this occurred on a brand new R2 installation on server 2008 SP2 is beyond me.  The OCS R1 system (on Server 2003 SP2 R2) did not have this issue, but the brand new setup did.  Go figure.

lcs 2005 revisited - ew

For the morbidly curious, in support of the LCS 2005 Migration Document project, I have been building (yet another) lab.

As of now, I have a fully functional (no PSTN :( ) LCS 2005 SP1 pool, Access Proxy, sited behind an ISA 2006.  And it connected first time through from my home network via the AP.

All this goodness running under Hyper-V.

Servers are ws03 r2 sp2.

Client is currently OC2005 on XP and OC2005 on win7beta.

A few notes:

WS03 r2 SP2 breaks ISA 2006 (I had forgotten).  This requires two separate reg hacks (disable RSS and Task offload)

Hklm\system\currentcontrolset\services\tcpip\parameters [dword EnableRSS = 0] [DisableTaskOffload = 1]

DNS stinks for LCS.

Certs came from a standalone CA on the DC.  An enterprise CA would not give me private keys on the certs unless I moved the DC to Server Enterprise which I was unwilling to do.

It is amazing what we have to re-learn at times, eh wot?

CA woes

My new project is kicking off, and my first task is to build my lab.

As the new project involves LCS 2005, I need to be able to issue PKI, so I installed my CA  - but I did it as an Enterprise CA on a ws03 Std server.

Because LCS 2005 is such a bear on certs, my first round of testing on the CA involved getting some test certs with SAN entries that included exportable private keys.  Just to make sure I can do it and have it be right the first time through.

This forced me to relearn certutil.exe and certreq.exe.

I also relearned certreq.inf files....very handy - I cannot believe I ever stopped using that method.  Well, I know why: OCS 2007 has a cert wizard that works really well.

At any rate it seems that there is no way to get an Enterprise CA running on ws03/08 standard edition server to give you private keys.  The issue is converting/duplicating the existing webserver template which makes the new template a v2 template - and to use that new template requires enterprise server edition.  arrrgh.

No amount of tweaking the inf file allowed me to get a private key with the cert - the private key simply is not included with the issued certificate.

My search for a solution will continue, as I need this to work.  My short term solution was to fall back to a Standalone CA, which allows the private keys very easily.  arrgh.  I wanted an Enterprise CA.