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

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,381)

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

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.

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.