- Windows XP Smart Card Logon, Digital Signature and Encryption Failures with Entrust SSP Issued HSPD-12 Certificates by Paul Fox, Senior Consultant, Microsoft Consulting Services
-
Background
On May 9th, 2009 Entrust Managed Services (provider of HSPD-12 certificates) performed a key update ceremony on the Entrust Managed Services Root and SSP certification authorities. HSPD-12 certificates issued after May 9th, 2009 will not work on the Windows XP operating system (i.e. RTM, SP1, SP2 and SP3).
More information concerning the Entrust key update can be found at http://sspweb.managed.entrust.com/emspkifsspcacertificateinformation.html
The following diagram depicts the PKI chaining (key match chaining method) of an HSPD-12 end entity digital signature certificate to the Common Policy root trust point as required per FIPS 201 architectural guidance.

Issue
Any Entrust MSO certificate issued after the key update ceremony will not properly validate its Extended Key Usage (a.k.a. Enhanced Key Usage) on the Windows XP operating system. The Extended Key Usage field is used to state the allowed usage of a certificate and is generally found only in end entity certificates. If the extension is present it must be used for the intended purpose. RFC 5280 states, “if a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications.”
The Entrust Managed Services Federal Root CA Link Certificate #2 (Cert Hash-sha1: 48 48 8c 9b 28 a5 ab d5 98 06 02 c1 d2 74 df d9 dd 43 c6 3f) contains the following in the Extended Key Usage field:
2.5.29.37: Flags = 0, Length = 13
Enhanced Key Usage
Any Purpose (2.5.29.37.0)
Unknown Key Usage (1.2.840.113533.7.74.3)
When tying to digitally sign an email on a Windows XP system the Entrust Managed Services Root CA Link Certificate #2 will have a yellow caution sign and a certificate status of “this certificate does not appear to be valid for the selected purpose.”

Cause
The Windows XP operating system was developed prior to the creation of the anyExtendedKeyUsage OID (circa 2001) and does not recognize the 2.5.29.37.0 OID. Note that the anyExtendedKeyUsage is not referenced in RFC 2459 (January 1999). Therefore any certificates that chains through the Entrust Managed Services Federal Root CA Link Certificate #2 will fail to work as intended on the Windows XP operating system. Any related HSPD-12 smart card application (i.e. smart card logon, digital signature and encryption) will fail on an XP system.

Resolution
HSPD-12 certificates issued by Entrust since May 9th, 2009 can be used on the Windows Vista and above operating systems. Crypt32.dll which is part of Vista, Windows Server 2008 and Windows 7 operating systems support the processing of the anyExtendedKeyUsage OID. It is recommended to upgrade the affected operating systems. For HSPD-12 smart card logon, digital signature and encryption applications to work on the XP operating system, Entrust will need to regenerate Entrust Managed Services Federal Root CA Link Certificate so that it does not include the anyExtendedKeyUsage nor the Entrust 1.2.840.113533.7.74.3 OIDs or explicitly state all associated HSPD-12 EKU OIDs within the Extended Key Usage field.
Acknowledgements
Microsoft would like to thank Wendy Brown (PGS) and Tom Connelly (SRA) of the Federal Public Key Infrastructure Authority (FPKIA) for identify and assisting in the troubleshooting of this issue.
References
· RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, http://www.ietf.org/rfc/rfc2459.txt
· RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, http://www.ietf.org/rfc/rfc5280.txt
· FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors, http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf
· Microsoft Product Lifecycle, http://support.microsoft.com/lifecycle/?LN=en-gb&C2=1173
· Entrust Managed Services Federal CA Shared Service Provider offering CA certificate information, http://sspweb.managed.entrust.com/emspkifsspcacertificateinformation.html
· How Certificates Work, http://technet.microsoft.com/en-us/library/cc776447(WS.10).aspx
· anyExtendedKeyUsage OID, http://www.oid-info.com/get/2.5.29.37.0
· Crypto Next Generation Features, http://msdn.microsoft.com/en-us/library/bb204775(VS.85).aspx
- Federal Posse at SharePoint Conference Key Note
-
SharePoint Conference Fun Fact
For those that are thinking about attending SharePoint Conference (SPC) in the spring, a little fact about this SPC. There are 300+ hours of content and 45+ hours of brand new hands-on labs. There are over 7000 attendees and the conference and hotel sold out 2 to 3 weeks before the conference.
SharePoint Conference Keynote
The SharePoint Conference kick-off with Steve Ballmer and his first time appearance at a SharePoint Conference was incredible. The next 2 hours was a whirl wind tour of features that would excite any public sector user. At its heart, SharePoint 2010 is going to scale to 100+ million of list items per document library or list, make connecting on any device or browser easier, allow for easy/fast connections to line-of-business, allow for enterprise management of taxonomy and document types (content types), provide a ReportBuilder Wizard, enable Document sets, and many other improvements that will help agencies be more Transparent.
Steve Ballmer/Jeff Teper Summary:
In his usual high energy presentation style, Steve drove home the following key messages:
- The goal of SharePoint 2010 is to drive the ability of technology to be a natural part of every moment of a day (meetings, symposiums, etc) to increase productivity and help us get out of the economic slowdown.
- Public Beta will be available in November.
- Cloud Integration – SharePoint Online Service and SharePoint 2010. SharePoint Online currently has over 1 Million users, updates quarterly, and hosting sizes well above 100,000 users. SharePoint 2010 wants to give you and your organization:
- Choice – Some things are in the cloud, some things are on-premise. You can mix and match, depending your needs.
- Depth – Includes Enterprise Features
- Proven – Large deployments. Years of experience of cloud services with high availability.
SharePoint Evolution
Many of you are familiar with the SharePoint feature wheel for MOSS 2007. However, this still left users struggling to understand what SharePoint was. So, SharePoint 2010 will now be talked about in how it solves 6 core scenarios/pillars of businesses instead of as a set of features. This will also help users and analysts map our best-of-breed and best-of-solution to the core pillars.

Here is a little more of an explanation of the newest concept “Composites”:
- Ease of creating Composite applications.
- Integrated Development Tools, Enhances Extensibility, Broad Support for Standards. Goal is to increase speed to solution and rapidly respond to business needs.
- XHTML, WCAG (Accessibility), REST, JSON, ATOM, and More…
- Support SharePoint Development of SharePoint on Windows 7 and Vista.
- BCS: Business Connectivity Services – This is new and improved Business Data Connector.
- Connect Line-of-business to SharePoint without any code through SharePoint Designer 2010 Wizard (5 clicks). Looks like a SharePoint list using a new “External List”. Available in SharePoint web experience and creates an External Links folder in Outlook as contact information.
VS2010 New Tools:
Below is a summary of new tools to help speed rapid development of solutions on SharePoint:
- New VS Templates: Site Definitions, Web Parts, Workflow, etc with Team Foundation Server integration
- SharePoint 2010 shows up in Server Explorer in VS2010. Wizards for Feature deployment at any level.
- Easy one-click debug, deployment, activation, installation, etc
- Developer Dashboard: Diagnostics, page load, SQL calls, etc help track down developer induced performance issues.
Overall, the investment we saw in making SharePoint development easy, fast, secure, and powerful was incredible.
-Your FedPosse
- SharePoint Conference 2009 Virtual Follow-along for Public Sector
-
To help those Public Sector members that couldn’t make it to the SharePoint Conference in Las Vegas to see and hear about all the cool new features in SharePoint 2010, all the new social networking features, office web applications, and even deeper Office client integration, the US Public Sector Team has put together a “posse” of bloggers and tweeters to help you follow-along virtually.
Unlike the overall SharePoint, our focus is also to point out things that would be of particular interest to the unique needs of Public Sector SharePoint Deployments (Federal, State, and Local governments.
If you are interested in following us, see details here.
Enjoy!
Dean Halstead
Collaboration Architect
Microsoft Federal Team
- Microsoft technology partner provides security at MLB All-Star Game
-
As President Obama stepped onto the mound to throw out the first pitch at last night’s MLB All-Star Game in St. Louis, E-SPONDER was providing local authorities with an integrated solution for planning, tracking and reporting all security matters during the game. The Microsoft Gold Certified Partner managed security at the Super Bowl earlier this year, and has upgraded its emergency response solution to include Bing Maps, Windows 7 Touch, SQL & OCS. Governor Jay Nixon even stopped by to see the solution in action, as St. Louis worked with the FBI, Coast Guard, Secret Service and a multitude of other agencies to keep the President and other visitors safe.
The Microsoft State and Local Government team was also on hand for last night’s game, and captured some great video of the solution and photos from the event. Through a multi-touch desktop running Windows 7 and enhanced mapping features powered by Bing Maps, users were able to point and gesture directly on the screen to navigate their surroundings. It’s a great example of how technology can bring multiple agencies together to share information in order to make informed, real-time decisions.
- Define “the cloud”
-
As I talk to people about cloud computing, I’ve found there are as many definitions of “the cloud” as there are people. One lady I talked to who works for a small municipality told me, “Our ISP now hosts one of our applications so we now have a cloud application.” Well that could be one definition… I guess, but hopefully the next few paragraphs will help define what Microsoft believes a cloud might look like.
The promise of cloud computing is fundamentally about reducing the complexity of delivering software. As an industry we have made some strides in this area, but most of that innovation has come around removing the complexity of installing, maintaining and optimizing hardware. We think there is an opportunity to move beyond hardware, and remove the complexity of the application platform itself: enabling our people to focus on their applications and end user experiences.
Think of cloud computing as a massive geo-distributed computer made up of disks, chips, racks, switches, load balancers and more distributed across the globe. This cloud could be public, meaning a multi-tenant environment with shared uniform policies across multiple tenants, or a private cloud where one organization or tenant owns all the hardware and connectivity typically managed for their own applications.
The Microsoft approach is to build an operating system that manages these massive geo-distributed computers and a development platform providing a rich set of services for managing applications and building blocks such as storage, identity and connectivity services for building applications.
- Claims enables ABAC
-
Earlier in this blog I introduced Geneva as a beta technology Microsoft is building into Windows Server 2008R2 to help manage the identity challenges. One capability the DoD would like to enable is Attribute Based Access Control (ABAC). Attributes about DoD services members are stored in many different directories across DoD. Right now DoD really has a very limited ability to access those attributes.
Think of this scenario: To access a specific web site, a person must be in the Air Force, have a secret clearance and their dental records must be up-to-date. Today, it is unlikely the capability exists to enable the scenario without creating a group, placing everyone who meets that criteria into that group and updating the group constantly. It would be much easier for a technology like Geneva to reach out to those different directories or databases and collect the attributes or claims, and once all the attributes were collected, present the token to the web site for access. The end user would likely never know the transactions for the attributes ever occurred.
Beta 2 for Geneva which is interoperable with other technologies and standards based is in beta 2 now. http://msdn.microsoft.com/en-us/security/aa570351.aspx
- SharePoint 2007 SP2 –Important Information
-
The SharePoint Product Team has posted a blog entry about a serious bug found in Service Pack 2. Essentially, if you have installed Service Pack 2 for Office SharePoint Server 2007, Project Server 2007, Form Server 2007, Search Server 2008 or Search Server 2008 Express your installation has been reset to think it’s a 180-Day trial version. 180 days after you have installed the Service Pack end users will no longer be able to access the system. This should not result in data loss and it is corrected by re-entering your Product ID numbers (PID) on the Convert License Type page in Central Administration or applying a hotfix that will be released as soon as possible.
The link to the SharePoint Team Blog entry is located here. http://blogs.msdn.com/sharepoint/archive/2009/05/21/attention-important-information-on-service-pack-2.aspx
- SharePoint Server 2010 goes all 64-bit
-
The SharePoint product team recently announced the preliminary system requirements for SharePoint Server 2010. The main reason for the announcement was to allow our customers and partners to start the planning and budgeting process for moving to SharePoint Server 2010. With this announcement SharePoint Server 2010 is now inline with the rest of the Information Worker (IW) server products – Exchange Server 2007 and the recently released Office Communications Server 2007 R2 were released as 64-bit only platforms.
Here are the main bullet points from the announcement (with my comments in italics below):
- SharePoint Server 2010 will be 64-bit only.
- The server components of SharePoint will only be 64-bit. You should also think about the SharePoint applications that you might be buying or building and determine if they too are/will be 64-bit moving forward.
- SharePoint Server 2010 will require 64-bit Windows Server 2008 or 64-bit Windows Server 2008 R2.
- This may seem obvious to most but if you are currently running the 32-bit versions of SharePoint Portal Server 2003 or SharePoint Server 2007 (anyone still running SharePoint Portal Server 2001?) you most likely have a 32-bit OS on that server. You’ll have to check to see if you have a 32-bit OS on 64-bit hardware. Either way you’re going to have to upgrade the OS to a flavor of 64-bit Windows Server 2008 – this may mean new hardware too.
- SharePoint Server 2010 will require 64-bit SQL Server 2008 or 64-bit SQL Server 2005.
- There will still be 32-bit versions of SQL Server, but SharePoint won’t be compatible/supported with them. The reason behind this is the performance gains that can be achieved with 64-bit over 32-bit. Also, from a testing standpoint, it will reduce the testing matrix for SharePoint 2010 as we won’t have to test for all the different versions of SQL Server 2005 and 2008.
- Internet Explorer 6.0 will no longer be supported as a client for SharePoint Server 2010.
- While not directly related to the SharePoint server platform, I think it’s important to know this moving forward. If you’re an organization that has not yet moved to Internet Explorer 7.0 or later and you plan on moving to SharePoint 2010, you’ll also have to plan a rollout of Internet Explorer 7.0 or 8.0. The reason for this is that we’re building for browsers with XHTML 1.0 compliance and Internet Explorer 6 falls short here and won’t be supported.
- On the other browser support topic, we’re planning on an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows Operating Systems as well.
You can find the official announcement here: http://blogs.msdn.com/sharepoint/archive/2009/05/07/announcing-sharepoint-server-2010-preliminary-system-requirements.aspx.
- Microsoft launches Open Government Data Initiative (OGDI)
-
Technology can be the best enabler of government transparency. At Microsoft, we believe we have a responsibility to contribute to technology to the community to help break down barriers to transparency.
To that end, on May 7, Microsoft announced the Open Government Data Initiative (OGDI) as part of our Open Government activities.
Microsoft is contributing software on CodePlex which will make it very easy for government organizations to publish their data on the Windows Azure cloud services platform. Whats different about publishing data with OGDI is that OGDI provides access to data via a commonly used web-friendly open REST-based approach. So not only will it be easy for people to browse data, OGDI-based repositories make it easy for *software* to access the data. Part of what we will publish is sample code for people with many different programming skills to write programs to access this data. So if you program in Ruby, Python, Flash, PHP, Javascript, .NET or Silverlight, you will have an immediate jump start for writing applications which use this data. And if you are a mapping junkie, we expose all the data that has geographic data as KML in a simple URL, so you can overlay data on maps like Google Maps and Virtual Earth. You can even cut and past the URL and enter it into Google Earth!
We used the very same code that we will put on CodePlex to create a working sample site, which we are calling an “Interactive SDK”. The site is located at http://ogdisdk.cloudapp.net. There is also a short video demonstration at the site, so we encourage you to check it out.
And if you are interested in working with us to use this code to create your own repository, please contact us at askogdi@microsoft.com, we’re eager to hear from you!
- Improved information sharing through Identity Management and Claims
-
As I look across the Department of Defense enterprise and commercial businesses for that matter, probably the greatest desire is also the greatest challenge facing technologists. The challenge is providing the capability to securely share information.
One aspect compounding the problem is the numerous methods of authenticating identity and levels of confidence of actually proving identity. Methods such as username/password, Kerberos and PKI are a few examples. Each of these methods has their benefits, pitfalls and vulnerabilities. As we look toward the future of identity management, what if I was able to use the same techniques in my virtual world as in my real world? For most users the transition to the virtual world could be smoother and more secure.
Here’s an example: I’m driving down a local Virginia highway when a state trooper a little concerned with my safety pulls me over (it could happen). He asks to verify my identity and authorization to operate a motor vehicle by presenting my drivers license. My driver’s license is really just a token verifying that I went to a location trusted by the trooper (the DMV) and presented a claim (my birth certificate) accepted by the DMV as proof of my identity. The driver’s license also provides validation of a claim I have proven some level of proficiency and knowledge (an attribute) required by the state of Virginia to operate a motor vehicle and of course, paid the appropriate fees (another attributes) to the city, county and state.
Let’s take that same scenario into the virtual world. I want to access a secure website outside of my enterprise (maybe to pay my speeding ticket… if that happened), and the web site owner doesn’t have an agreement with my enterprise to access and validate my identity. If there was a trusted 3rd party, such as the DMV, they could provide the validation of my claims to access the web site. The basic process to access the web site is: 1) I attempt to access the web site which my browser learns requires attributes about me prior to authorizing access. The web site also provides a list of trusted 3rd party identity services including the DMV. 2) The browser redirects a request to DMV “Secure Token Service (STS)” to validate my identity. 3) User interface application presents itself with a virtual driver’s license I’ve previously configured. I select the virtual driver’s license, the exchange is made between the STS, the virtual drivers licensing and my browser and I’m issued a token. 4) The token with the appropriate claims is routed back to the secure website and within seconds of the original request I’m granted access. Notice, no username or password information was exchanged.
Microsoft is investing in claims and has a new technology with the project name Geneva. Geneva provides:
· Framework for building .NET applications that use claims to make user access decisions STS,
· Server security token service (STS) for issuing and transforming claims, enabling federations, and managing user access
· Windows CardSpace for helping users navigate access decisions and for developers to build customer authentication experiences for users
Geneva is standards based technology enabling existing systems to interoperate with new systems such as cloud services and SOA.
David Chappell, an independent consultant wrote an excellent paper on claims and “Introducing Geneva”.
Over the next several weeks I will continue to build on the Claims concept and present more specific examples of how claims based identity management can offer methods to improve security for identity management and information sharing.
- Logical Access (smart card logon) requirement and PIV cards
-
Homeland Security Presidential Directive-12 and FIPS 201-1 topics are still the subject of much confusion on how to implement, across the federal government. After several years of establishing the systems to issue the Personal Identity Verification (PIV) credentials, the focus is now around usage of the PIV cards for logical access and physical access rather than simply another ID badge. Some of the larger agencies i.e. USDA, Department of State and others have figured out the requirements to use these credentials in their networks for smart card logon primarily with Microsoft Windows; however, many smaller agencies still have questions on what to do next.

This blog entry is intended to:
- Provide information so that anyone with a requirement for logical access using PIV cards will know what the steps are they can take to help meet HSPD-12 and OMB 05-24.
First to support the use of smart cards for network authentication, we assume that the agency or department has already completed the following, in accordance with the dates established by the OMB.
- Implemented a compliant FIPS-201-1 PIV Card Issuing (PCI) System, or have signed with either GSA's managed service offering - USAccess or another shared service provider solution for user sponsorship, registration, issuance and activation of the PIV credential.
- Have selected a PIV middleware vendor and solution for use in the organization.
- Have selected a smart card reader compatible with the OS and approved for use on FIPS201 Approved Products List.
In addition to the aforementioned items, if the agency is planning on using the PIV cards for smart card logon, to Microsoft Windows XP, Windows Vista or later operating system, then the following requirements must also be addressed by the organization to successful logon with the PIV cards to the network.
Microsoft Windows XP SP2 and SP3, in a Microsoft Windows Server 2003 forest has the following requirements for smart card logon. With Windows Vista and the upcoming Windows 7, the UPN and Smart Card Logon EKU are optional, more information is available here; however, for today let's focus on Microsoft Windows XP.
- The x.509 certificate issued to the end entity must have enhanced key usage of Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2), the subject alternative name field must be populated with a UPN value.
- The x.509 certificate issued to the end entity must have the CRL Distribution Point (CDP) populated.
- Key usage must be of type "Digital Signature".
For HSPD-12 PIV card certificates issued under the Federal Common Policy Framework, these certificate properties are populated and meet the requirements. However, there are infrastructure requirements that also need to be addressed by each agency, wishing to use their employee and contractor PIV cards for network smart card logon. The order of steps below are of no particular significance, however, all must be completed for a successful implementation.
- The issuing CA, that issued the user's PIV_authentication certificate MUST be trusted by the organization's forest in the NTAuth container. A copy fo the certificate from the CA in a base64 encoded file format can be published by an Enterprise Administrator or Schema Administrator from a member server using CERTUTIL -DSPUBLISH ["nameofthefile"].CER NTAuthCA. This step basically states that the CA is trusted by the forest and domain controllers (DCs) for issuing of credentials to be used for network authentication.
- The ROOT CA of the certificate chain must be trusted by each client and DC that will participate in the network authentication process. For HSPD-12, this will almost always be the "Common Policy" or the Federal Bridge Cross Certification Root, depending on how the agency established their trust to the federal root CAs. For the certificate to be trusted, there are several ways to get the certificate, 1) Microsoft Certificate Update Program, clients configured properly will download this file from the Microsoft Update site, 2) download from the AIA location in a subordinate certificate and publish to forest manually, 3) acquire from GSA, or Federal PKI Policy Authority (FPKIPA) and publish manually. To manually publish the file to the organization's forest so that all clients and DCs will trust the root, use CERTUTIL -DSPUBLISH ["nameoffile"].CER RootCA from a domain member server with Enterprise or Schema Administrator rights.
- The CDP and\or the Online Certificate Status Protocol (OCSP) responder referenced in the leaf certificates must be accessible by the DCs that will process the authentication request. Note, if you have NOT deployed Microsoft Windows Server 2008 and OCSP is your preferred validation method, then a third party OCSP client will be required. OCSP client functionality is an inherent capability in Microsoft Windows Vista, Windows 7 and Windows Server 2008.
- Each DC server that will process authentication requests, MUST also be issued a DC Authentication Certificate for mutual authentication with the clients during the Kerberos PKINIT process. This DC Authentication certificate can be an internally issued certificate, exclusive of the PKI chain used for the PIV credentials. FIPS and the x.509 Common Policy Framework intends on issuing strong credentials to users at the MEDIUM and HIGH Assurance Profiles; it is important to note that each of these profiles requires a face to face identity vetting process. The administrators for DCs are not likely to request DC Authentication certificates by meeting with the issuance authority face to face for each DC. Therefore, an internal Microsoft Windows Server 2003 or 2008 CA deployed in accordance with the organization's policies is capable of automatically enrolling, renewing and deploying the certificates to the DCs; this process is called "auto enrollment and auto renewal". However, if the agency's policy requires the use of a third party CA or purchase of certificates from a service provider, the certificates can be requested using PKCS and installed on each DC manually. The external DC certificate process requires a manual request, installation, renewal and maintenance of the DC Authentication certificates. In addition, for external DC Authentication certificates, each client on your network will require access to the CDP, OCSP and AIA locations in the DC certificates for validation during the PKIINT process; if the root for the DC certificates is not already trusted, a trust as previously described will need to be established.
The following are additional items that should be verified, for the smart card logon process to be successful...
- Each client machine MUST also be a member of the forest/domain that they will attempt to authenticate to; non-domain joined machines cannot participate in smart card logon.
- Each user object in the forest must have a matching UPN value in certificate. For example, John Doe at agency.gov with a PIV card from USAccess issued with 19202837@fedidcard.govas the UPN will not authenticate if the domain user object has a UPN of john.doe@agency.gov. Therefore, the UPN in the domain will need to be changed to match the value in the certificate, and the suffix "fedidcard.gov" must be added to the forest. Click here for more information. Of course if you submitted the user's registration to USAccess with your own internal UPN values, then no change should be required for the authentication to work. USAccess supports both options, and agencies with their own PCI System will have flexibility to use whatever value makes the most sense for their implementation.
This posting is provided "AS IS" with no warranties, and confers no rights.