Hasain Alshakarti

I en bunker långt under Normalms gator finns “The Nerd Herd” studion, där produceras det varje vecka tunga teknikprogram med erkända experter!

Tillsammans med Johan Persson, Michael Anderberg och Fredrik ”DXter” Jonsson försöker vi under detta avsnitt ge våra synpunkter och tankar om och kring PKI i och PKI relaterade frågor och funderingar…

Avsnittet kan laddas ner här… (Du kan även prenumerera på showen i iTunes och gPodder – ge gärna en positiv review också, så att fler kan hitta showen, tack!)

Du kan givetvis följa The Nerd Herd på http://thenerdherdse.wordpress.com, DXter på hans blogg http://poweradmin.se

/Hasain

Yet another day of troubleshooting DirectAccess, this time it was my colleague and friend Mikael Nystrom asking about expired IPHTTPS and NLS certificates. He already knew about my other post about changing the IPHTTPS certificate.

So he did delete the old binding by using the [netsh http del sslcert] command for both external addresses, and did replace the binding by using the [netsh http add sslcert] and/or the IIS management console.

Now the DirectAccess server is restored in functional state again but Mikael realized another error, the DirectAccess Management Console started showing an error about not being able to read the XML config file due to errors in certificate hashes for the IpHttpsCertHash and NidCertHash?

Now my advice was to manually edit the %WINDIR%\DirectAccess\DirectAccessConfig.xml file and replace the certificate thumbprints in the file with the new ones from the renewed certificates. But the console was still complaining about the hashes! After some thinking and when comparing the old and the new config files we realized that the console needed the certificate hash values in CAPITAL letters!!!!

Yes, the certificate hash/thumbprint is a hex representation, and according to W3C XML Schema Part 2: Datatypes Second Edition http://www.w3.org/TR/xmlschema-2/#hexBinary:

hexBinary has a lexical representation where each binary octet is encoded as a character tuple, consisting of two hexadecimal digits ([0-9a-fA-F]) representing the octet code. For example, “0FB7” is a hex encoding for the 16-bit integer 4023 (whose binary representation is 111110110111).

Reading the above carefully, any developer can simply realize that the expression “digits ([0-9a-fA-F])” means not case sensitive, but this does apparently not apply to whom ever developed the DirectAccess Management Console in Windows Server 2008 R2

To change any of the IPHTTPS or NLS (if NLS is running on the DA server) certificate and keep the DA Management Console happy:

• Redo the certificate bindings either using the netsh http del/add sslcert command or the IIS console
• Change the IpHttpsCertHash and NidCertHash in the DirectAccessConfig.xml file and make sure the hash value is in CAPITAL letters

If you happen to know the person responsible for this at Micrososft, please give him/her the link to W3C 😉

Once someone has an Enrollment Agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization, including all domain admins. The resulting smart card could then be used to log on to the network and impersonate the real user. Because of the powerful capability of the Enrollment Agent certificate, it is strongly recommended that your organization maintain very strong security policies for these certificates.

Permitting an enrollment agent to enroll only a certain type of certificate to a certain group of users was not possible before Windows 2008. In Windows Server 2003 Enterprise Edition the enterprise CA does not provide any configurable means to control enrollment agents except by enforcing the application policy extension of the enrollment agent certificate, which verifies that the credentials grant the ability to enroll on behalf of other users, including the domain admins.

In Windows Server 2008 the PKI architecture of an enterprise has the possibility to restrict enrollment agents so that enrollment is only possible for a certain certificate template and a certain group of users. By providing a technical possibility to limit the scope of enrollment agents, an enterprise can is given a better tool to control the delegation of trust and the risk associated with granting that trust.

On a Windows Server 2008 Enterprise-based certification authority (CA), the restricted enrollment agent features allow an enrollment agent to be used for one or many certificate templates. For each certificate template, you can choose which users or security groups the enrollment agent can enroll on behalf of.

Note: The feature cannot constrain an enrollment agent based on a certain Active Directory organizational unit (OU) or container; you must use security groups instead. The restricted enrollment agent is not available on a Windows Server® 2008 Standard-based CA.

By using the Certificate Services snap-in, you can create a permissions list for each enrollment agent to configure which users or security groups an enrollment agent can enroll on behalf of for each certificate template.

To enroll for a smart card certificate on behalf of someone, the user must have an enrollment agent certificate. The smart card enrollment agent can create smart cards on behalf of any user, including an enterprise administrator.

Follow the steps below to create an enrollment agent trusted to enroll for a smart card certificate on behalf of other users:

Create an Enrollment Agent enabled Smart Card Certificate Template:

1. Open the Certificate Template Management console
2. Right click the Smartcard User or Smartcard Logon template and choose Duplicate Template
   Note: If you are using a Windows 2008 CA or above you will be prompted to select the minimum CA for your new template. Select the 2003 Enterprise option.
3. Provide a name for the smart card template and set the validity period that you desire for the environment
4. On Request Handling tab, do the following
• Select Signature and smartcard logon under Purpose
• Under CSPs, select the CSP that should be used for your smart cards
5. On Issuance Requirements tab, do the following
• Select The number of authorized signatures: and set it to 1
• Under Policy type required in signature, select Application Policy
• Under Application Policy select Certificate request Agent
6. On the Security tab, make sure the user or group that is designated as enrollment agent has Read and Enroll permissions on the template
7. Click Apply and then OK.
8. Close Certificate Templates console
9. In the Certificate Authority snap-in, right click Certificate Templates folder and select New
10. Select “Certificate Template to Issue”
11. Select the new template and click Ok

Specify/adjust the permissions of the Enrollment Agents and publish the Enrollment Agent certifiacte template:

1. Open the Certificate Template Management console
2. Right-click the EnrollmentAgent template, and then click Properties
3. On the Security tab, make sure the user or group designated as an enrollment agent has Read and Enroll permissions on the template, and then click OK
4. In the Certificate Authority snap-in, right click Certificate Templates folder and select New
5. Select “Certificate Template to Issue”
6. Select the Enrollment Agent template and click Ok

Create a smart card certificate for a user using the new smart card template and the enrollment agent:

1. Log on to system that has a smart card reader with a user that has an Enrollment Agent certificate
2. Open certmgr.msc
3. Expand Personal, and then right-click on the Certificates folder
4. Select All Tasks > Advanced Operations > Enroll on behalf of from the context menu
5. Click Next
6. When prompted, browse to the signing certificate for the enrollment agent. Click Next
7. Select the certificate template you created, and click Next
8. Browse and select the user name (This will be the subject of the smartcard certificate) Click Enroll

The certificate selection user interface in Windows supports filtering logic to provide a simplified user experience when an application presents multiple certificates. But some applications are not designed to use filtering logic (developers not aware of functionality…) or uses filters that does not provide efficient reduction of the number of certificates presented to the user making it almost impossible for a user to know witch certificate to choose unless opening the certificate and looking at the details of template name, EKU, etc.

This is particularly true when all certificates has been automatically enrolled using the same user DN/CN attribute based on the users Active Directory user object attributes. In addition to that, Autoenrollment does not support variations in certificate subject name unless using some third party policy module installed on the Active Directory Certificates Services.

Knowing that the certificate selection UI supports certificate friendly names. Setting the certificate friendly name to include information about the certificate template can simplify the users task to select the correct certificate.

Friendly names are properties in the X.509 certificate store in Windows that can be set at any time after the certificate has been created/installed in the store.

One way to set the friendly name is through the certificate MMC SnapIn. Alternatively certutil.exe can be used in the following way:

Create a text file containing the following information:

[Version]
Signature = “$Windows NT$”
[Properties]
11 = “{text}My Friendly Name”

Save the file as friendlyname.inf

Determine the serialnumber of the certificate where the friendly name should be changed.

Run the following command at a command-line:
certutil –repairstore –user my {SerialNumber} FriendlyName.inf

Automating the friendly name can be achieved by either automating/scripting the steps above alternatively by creating a tool that enumerates all certificates in the personal store and assign the friendly name.

A proof of concept CertFN.exe tool was created to automate the above. The tool receives a parameter for the template name to use when filtering the user store, it then sets the friendly name based on the schema “Template Name – Certificate Subject Name”

  CertFN - Certificate Friendly Name Tool download:(39.3 KiB, 4,437)

  CertFN - Certificate Friendly Name Tool - The Powershell Edition download:(1.1 KiB, 5,668)

The Basics of PKI

Public Key Infrastructure (PKI) refers to the set of hardware, software, people, policies, and procedures necessary to create, manage, store, distribute, and revoke certificates based on public key cryptography. The characteristic operation of PKI is known as certification (the issuance of certificates). PKI certification provides a framework for the security feature known as authentication (proof of identification).

Understanding the role of PKI in identity management involves the following basic terms:

• The Public/Private Key Pair – The mathematics of public/private key pairs is beyond the scope of this guide, but it is important to note the functional relationship between a public and a private key. PKI cryptographic algorithms use the public key of the receiver of an encrypted message to encrypt data, and the related private key and only the related private key to decrypt the encrypted message.
• Digital Signature – A digital signature of a message is created with the signer’s private key. The corresponding public key, which is available to everyone, is then used to verify this signature. The secrecy of the private key must be maintained because the framework falls apart after the private key is compromised.
• Certification Authority (CA) – An authority that trusted to create and issue certificates that contain public keys acting as a trust in a public key infrastructure and providing services that authenticate the identity of individuals, computers, and other entities in a network.
• Certificate – A data structure containing an entities public key and related identification information, which is digitally signed with the private key of the CA that issued it. The certificate securely binds together the information that it contains; any attempt to tamper with it will be detected at the time of use.
• Self-signed – In a self-signed certificate, the public key in the certificate and the key used to verify the certificate are the same. Some self-signed certificates are designated as Root CAs.
• Root CA – A root CA is a special class of CA, which is trusted unconditionally by a client and is at the top of a certification hierarchy. All certificate chains terminate at a root CA. The root authority must sign its own certificate because there is no higher certifying authority in the certification hierarchy.
• Subordinate CA / Intermediate CA / Cross CA / Bridge CA – A CA that has been certified by another CA. Subordination creates a managed trust between separate certification authorities resulting in CA hierarchies.
• Certificate policy and practice statements –  The two documents that outline how the CA and its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the trust is broken, and so on.
• Public key standards – Standards are developed to describe the syntax for digital signing and encrypting of messages and to ensure that a user has an appropriate private key. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, as specified in RFC5280 is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for the Internet.
• Revocation and Expiration – Certificates are issued with a planned lifetime, which is defined through a validity start time and an explicit expiration date. Once issued, a certificate becomes valid when its validity time has been reached, and it is considered valid until its expiration date. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA, and compromise or suspected compromise of the corresponding private key. Under such circumstances, the issuing CA needs to revoke the certificate.
• Registration Authority (RA) – A Registration Authority vouches to a CA for the binding between public keys and the identity and attributes of a prospective certificate holder. Essentially, using the RA is a form of administrative delegation—the CA delegates to the RA the task of verifying the binding of a public key to an entity.
• Certificate Chains – A certificate chain consists of all the certificates needed to certify the subject identified by the end certificate. In practice this includes the end certificate, the certificates of intermediate CAs, and the certificate of a root CA trusted by all parties in the chain. Every intermediate CA in the chain holds a certificate issued by the CA one level above it in the trust hierarchy.

Microsoft IT has released an updated version of the “Public Key Infrastructure at Microsoft” whitepaper found at http://www.microsoft.com/download/en/details.aspx?id=27581 or here Public Key Infrastructure at Microsoft 1750_PKI_TWP

The update deals with changes to the Microsoft internal PKI structure as part of the Windows Server 2008 R2 migration. There are many good “lessons learned and best practicess” outlined by Microsoft IT as a result of the migration/upgrade process that was performed.

Some of my favorites are the way they use CRL Overlap to provide higher availablity of CRLs and the simplified two tier structure together with Cross Forest Enrollment and the discussions about virtualisation of CAs

Some of the highlighted features in the document are:

Windows Server 2008:

• Improved enrollment capabilities that enable delegated enrollment agents to be assigned on a per-template basis
• Enhanced performance monitoring with the addition of new performance counters
• Scalable, high-speed revocation status response services that combine CRLs and integrated Online Responder services
• Support for Cryptography Next Generation (CNG) to enable the use of Suite B algorithms
• Enhanced service monitoring with the introduction of the Windows Server 2008 AD CS Management Pack for Microsoft Operations Manager 2005
• More detailed server administration with restricted certificate managers
• Failover cluster support

Windows Server 2008 R2:

• Cross-forest enrollment capability that allows for consolidation of existing hardware
• Databaseless CA feature to avoid storing unnecessary certificate records
• Best Practice Analyzer for improved configuration practices
• Web-based certificate enrollment protocol to allow enrollment over the Internet

SYMPTOMS:

• You install the Routing and Remote Access Service (RRAS) role on a server that is running Windows Server 2008 R2.
• You configure the server to accept Layer Two Tunneling Protocol with IPsec (L2TP/IPsec) connections.
• You run the Netsh ipsec dynamic set config property=strongcrlcheck value=2 command to configure the StrongCRLCheck setting on the server.
• You revoke a certificate on a client computer. The certificate is used to make L2TP/IPsec connections to the RRAS server.
• You establish an L2TP/IPsec connection from the client computer to the server.
• The connection to the RRAS server is successful. However, you expect that the client computer cannot connect to the server.

CMC certificate requests are normally used in combination with EOBO enrollment (Enroll On Behalf Of) scenarios where additional enrollment agent signatures are required by the certification authority to accept and process the certificate request.

Generating and signing the CMC certificate request can either be done using the certmgr.msc MMC snap-in or scripted using the certreq.exe tool provided in the Windows platform. The procedure using certreq to generate and sign the CMC certificate request is defined by the following steps

1. Create a certificate request inf file describing the request, below you find a sample inf file for EOBO request

[Version]
Signature= “$Windows NT$”

[NewRequest]
RequesterName = Crisco0\Administrator
RequestType = CMC

[RequestAttributes]
CertificateTemplate = EOBO_Template

2. Generate the initial self signed CMC certficate request using the command:

certreq.exe -new certificate_request.inf certificate_request.req

3. Sign the initial self signed CMC certficate request with the enrollment agent certificate using the command:

certreq.exe -sign certificate_request.req signed_certificate.req

4. Submit the agent signed CMC request to the enterprise CA and receive the certificate using the command:

certreq.exe -submit signed_certificate.req new_certificate.cer

The procedure described above works as expected until you try it in Windows 2008 R2 SP1 (I have not had the chans to test other versions yet) and you will get an error message at step 3 failing the agent signing.

What happens in step 3 is that the certreq tools will try to read the referenced certificate template from Active Directory and to figure out the signing requirements and it simply fails with the error message:

Certificate Request Processor: An attempt was made to perform an initialization operation when initialization has already been completed. 0x800704df (WIN32: 1247)

After struggling with my request inf file and certificate template with the same error I decided to perform the agent signing using other tools, after some research I found this very interesting MSDN article http://msdn.microsoft.com/en-us/library/ms867026.aspx  about Creating Certificate Requests Using the Certificate Enrollment Control and CryptoAPI. The article looked nice with provided samples but I wanted something more simple so I ended up in this article http://technet.microsoft.com/en-us/library/ff182315(WS.10).aspx about “Create Enroll on Behalf of Another User Request”. Usingthe code from the “Create Enroll on Behalf of Another User Request” article I created the cmcSigner tool and the CMC request could be signed and the certificate issued without errors.

What if this version certreq.exe has some issue? To figure out that I decided to test the certreq -sign operation with an older version of certreq.exe so I grabbed the Windows 2003 Admin Tool Pack and extracted the certreq.exe and tested the signing step with no errors!

Conclusion: certreq.exe in some later versions has a problem performing a certificate signing operation.

Solution: use another version of certreq.exe or another tool like the cmcSigner tool

  cmcSigner Tool download:(258.8 KiB, 3,626)

Some interesting FIM CM 2010 links from Microsoft Donwloads:

Test Lab Guide: Demonstrating Forefront Identity Manager 2010 Certificate Management Smart Card Centralized Registration

Demonstrating FIM CM using a centralized smart card registration model in a test lab.

Test Lab Guide: Demonstrating Forefront Identity Manager 2010 Certificate Management User Smart Card Self-Service

Demonstrating User Smart Card Self-Service using FIM CM in a test lab.

Test Lab Guide: Demonstrating Forefront Identity Manager 2010 Certificate Management Delegated Smart Card Registration

Delegated smart card registration with FIM CM in a test lab.

Test Lab Guide: Demonstrating Forefront Identity Manager 2010 Certificate Management User Certificate Self-Service

Demonstrate using FIM CM for Self-Service certificate management.

Test Lab Guide: Installing Forefront Identity Manager 2010 Certificate Management with Constrained Delegation, Update 1, and FIM 2010 Integration

Install FIM CM with Constrained Delegation, Update 1, and FIM 2010 in a test lab.

Internet Explorer 7 and later. In order to confirm the identity of organizations that host secure webpages, certifying authorities issue security certificates. These certificates are validated when you request a secure webpage.

By default, Internet Explorer performs a number of steps in order to validate the security certificate for a secure website. If a certificate is invalid, is out-of-date, or improperly identifies the website in question, Internet Explorer displays a notification to the user.

As an additional verification step, many certifying authorities also provide a service that identifies certificates that have been recently revoked. Earlier versions of Internet Explorer displayed notifications when this service could not be reached.

Because the inability to reach these services does not necessarily indicate that a certificate has been revoked, many users complained that such notifications were “false positives.” After considerable negative feedback, these notifications were disabled by default in Internet Explorer 7 and later.

When enabled, the FEATURE_WARN_ON_SEC_CERT_REV_FAILED feature displays notifications when Internet Explorer cannot reach the certificate revocation service published by a certifying authority. By default, this feature is disabled for Internet Explorer. This feature is not supported for applications hosting the WebBrowser Control.

To enable this feature using the registry, add the name of the Internet Explorer executable file to the following setting.

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]
“iexplore.exe”=dword:00000001

The feature is enabled when the value is set to (DWORD) 00000001 and disabled when the value is (DWORD) 00000000.

It is pretty straight forward to configure SSL Client Certificate Authentication in UAG, just follow the steps in the online guide at http://technet.microsoft.com/en-us/library/ee861163.aspx and you should be able to run in almost no time except for an issue that occurs whenever your logon name and  common name does not match!

An authentication error will occur with the error message in UAG telling that the user account does not have the expected cn, upn or email value that has been extracted from the users SSL authentication certificate at the time of logon. Looking at the certificate all values of cn, upn and email shows a 100% match of the same values on the user account!

Looking at the cert auth scripts in UAG we can see that UAG is using the value of the common name of the certificate subject as the user_name. The user_name is then used to obtain information from Active Directory regarding that user account. And this is where the error occurs, the matching for the username is simply wrong.

To correct this you can obtain the UPN value from the client certificate in the certificate validation script and use that value to obtain the user logon name by simply splitting at the @ sign.

Download the UAG customupdate-cert scripts and make sure to change the authserver01 key word to the name of your authentication repository.

/Hasain