$psiApp = New-Object System.Diagnostics.ProcessStartInfo $psiApp.FileName = "YourApp.exe" $psiApp.UseShellExecute = $false $psiApp.RedirectStandardInput = $true

$prcApp = [System.Diagnostics.Process]::Start($psiApp)

While (!$prcApp.HasExited) { $prcApp.StandardInput.WriteLine("y")

      Start-Sleep -Milliseconds 500 }

• FileName: The path to the file you wish to create the process from
• UseShellExecute: This determines whether the file is launched using shell execute (think start.exe) or not.  Using shell execute means that the FileName can specify non-executable files with file associations (for example, a .docx document would launch Microsoft Word and open the document).  With ShellExecute disabled, the file in FileName must be executable.
• RedirectStandardInput: This property enables us to programmatically write text directly to the STDIN pipe to the process.  We will use this to send in our series of Y's.

#******************************************************************************
#* <Function Start-RemoteProcess>                                             *
#*                                                                            *
#* This function uses WMI to start a process on a remote computer.            *
#*                                                                            *
#* Input:                                                                     *
#*     [string] $Path - path to the file to execute                           *
#*     [string] $Computer - computer to create the process on                 *
#*              $Window {                                                     *
#*                  "Hidden" - hide the process window                        *
#*                  "Normal" - activate and display the window (default)      *
#*                  "Minimized" - minimize the window                         *
#*                  "Maximized" - maximize the window                         *
#*              }                                                             *
#*     [string] $StartPath - the starting path for the application            *
#*     [string] $Title - set the title of the window                          *
#*     [switch] $Priority {                                                   *
#*                  "Realtime" - set the process priority to realtime         *
#*                  "High" - set the process priority to high                 *
#*                  "AboveNormal" - set the process priority to above normal  *
#*                  "Normal" - set the process priority to normal (default)   *
#*                  "BelowNormal" - set the process priority to below normal  *
#*                  "Idle" - set the process priority to idle                 *
#*              }                                                             *
#*     [int]    $X - set the x position of the window                         *
#*     [int]    $XSize - set the width of the window                          *
#*     [int]    $Y - set the y position of the window                         *
#*     [int]    $YSize - set the height of the window                         *
#*     [PSCredential] $Credential - Credentials to connect to the computer    *
#*     [switch] $Elevate - Elevate the process in UAC                         *
#*                                                                            *
#* Output:                                                                    *
#*     [wmiobject]"Win32_Process" - the process that was created              *
#******************************************************************************
function Start-RemoteProcess {
    param(
        [Parameter(
            Mandatory=$True,
            ValueFromPipeline=$True,
            HelpMessage='The process to start on the computer')]
            [string] $Path,
        [Parameter(
            HelpMessage='The computer to start the process on')]
            [string] $Computer = ".",
        [Parameter(
            HelpMessage='The starting working path for the application')]
            [string] $StartPath = "c:\windows\system32\",
        [ValidateSet("Hidden", "Normal", "Minimized", "Maximized",
            IgnoreCase= $True)]
            [Parameter(
            HelpMessage='What state to start the program window')]
            $Window = "Normal",
        [Parameter(
            HelpMessage='The title to assign to the window')]
            [string] $Title,
        [ValidateSet("RealTime", "High", "AboveNormal", "Normal",
            "BelowNormal","Idle", IgnoreCase=$True)]
            [Parameter(
            HelpMessage='What priority to assign the new process')]
            $Priority = "Normal",
        [Parameter(
            HelpMessage='The starting X position of the window')]
            [int] $X,
        [Parameter(
            HelpMessage='The width of the window')]
            [int] $XSize,
        [Parameter(
            HelpMessage='The starting Y position of the window')]
            [int] $Y,
        [Parameter(
            HelpMessage='The starting height of the window')]
            [int] $YSize,
        [Parameter(
            HelpMessage='Credentials to connect to the remote computer')]
            [PSCredential] $Credential,
        [Parameter(
            HelpMessage='Elevate the process in User Account Control')]
            [switch] $Elevate = $False
    )
   
    #Create a new instance of W32_ProcessStartup
    $wmiProcessStartup = [wmiclass]"Win32_ProcessStartup"

    #Set the window state for the process
    switch($Window) {
        "Hidden" {$wmiProcessStartup.Properties['ShowWindow'].Value = 0}
        "Minimized" {$wmiProcessStartup.Properties['ShowWindow'].Value = 2}
        "Maximized" {$wmiProcessStartup.Properties['ShowWindow'].Value = 3}
    }

    #Set the window title if specified
    if ($Title -ne $Null) {$wmiProcessStartup.Properties['Title'].Value = $Title}

    #Set the process priority, if specified
    switch($Priority){
        "RealTime" {$wmiProcessStartup.Properties['PriorityClass'].Value = 256}
        "High" {$wmiProcessStartup.Properties['PriorityClass'].Value = 128}
        "AboveNormal" {$wmiProcessStartup.Properties['PriorityClass'].Value = 32768}
        "BelowNormal" {$wmiProcessStartup.Properties['PriorityClass'].Value = 16384}
        "Idle" {$wmiProcessStartup.Properties['PriorityClass'].Value = 64}
    }

    #Set the window X position if specified
    If ($X -ne $Null) {$wmiProcessStartup.Properties['X'].Value = $X}

    #Set the window Y position if specified
    If ($Y -ne $Null) {$wmiProcessStartup.Properties['Y'].Value = $Y}

    #Set the window width if specified
    If ($XSize -ne $Null) {$wmiProcessStartup.Properties['XSize'].Value = $XSize}

    #Set the window height if specified
    If ($YSize -ne $Null) {$wmiProcessStartup.Properties['YSize'].Value = $YSize}

    if ($Credential -eq $Null) {
        #Credentials were not specified
        If ($Elevate) {
            #Elevation was requested
            return Invoke-WmiMethod -ComputerName $Computer -Class "Win32_Process" -Name Create -EnableAllPrivileges -ArgumentList $Path, $StartPath, $wmiProcessStartup
        } else {
            #Elevation was not requested
            return Invoke-WmiMethod -ComputerName $Computer -Class "Win32_Process" -Name Create -ArgumentList $Path, $StartPath, $wmiProcessStartup
        }
    } else {
        #Credentials were specified
        If ($Elevate) {
            #Elevation was requested
            return Invoke-WmiMethod -ComputerName $Computer -Class "Win32_Process" -Name Create -EnableAllPrivileges -ArgumentList $Path, $StartPath, $wmiProcessStartup -Credential $Credential
        } else {
            #Elevation was not requested
            return Invoke-WmiMethod -ComputerName $Computer -Class "Win32_Process" -Name Create -ArgumentList $Path, $StartPath, $wmiProcessStartup -Credential $Credential
        }
    }
}

#******************************************************************************
#* </Function Start-RemoteProcess>                                            *
#******************************************************************************

• Does one of the asserted identification attributes match the identity of the principal supplying the certificate?
• Is the certificate being used in an authorized capacity?
• Does the certificate chain to a certificate listed in the "Trusted Root Certification Authorities" certificate store?
• Is the certificate revoked?

Validating the Identity of the Certificate Owner

In many cases, certificates are designed to provide identification of the computer or person holding the corresponding private key.  For example, when a user provides their Windows Live credentials to log on to a website the computer will validate that the certificate being used by the web server is authorized for the URL the user is accessing.  Another example of this is when you receive a digitally signed e-mail; the e-mail signature is only valid if the sender's e-mail matches the e-mail address listed on the certificate (under RFC822 Name).

In the initial two versions of the X.509 standard the only way to assert an identity was to use the "Subject" field of the certificate.  This field contains the X.500 address (also referred to as the LDAP distinguished name) of the object whose identity is being asserted.  As mentioned in my previous blog entry on the X.509 certificate, this is a throw back to the roots and original intent for PKI: directory services.  Later, when version 3 of the X.509 standard was passed, the "Subject Alternative Name" (sometimes referred to as a "SAN" field) was added allowing the issuer additional flexibility in specifying the identity of the authenticating entity.  Out-of-the-box this provided options to identify the certificate owner in any of the following ways (ref: http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=%2Fcom.ibm.help.domino.admin.doc%2FDOC%2FH_KEY_USAGE_EXTENSIONS_FOR_INTERNET_CERTIFICATES_1521_OVER.html):

• RFC 822 Name
  Another name for rfc822Name is the subject's e-mail address
• DNS Name
  A DNS name meeting specifications outlined in RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt)
• X.400 Address
  The X.400 standard governs message handling and look similar to the X.500 directory services standard, however addressing elements such as the country name, organization name, given name, surname, initials, etc.)
• Directory Name
  This is the distinguished name of the subject
• Electronic Data Identifier (EDI) Party Name
  The ediPartyName attribute allows the certificate to specify an alternative authority (referred to as a nameAssigner) that has assigned a name to the subject.  An example of where this might be of use is in federation whereby another directory service is asserting the name of a certified entity.
• Uniform Resource Identifier (URI)
  This field contains a uniform resource identifier, or URI, conforming to RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt).  URIs usually look similar to a uniform resource locator (URL), however they are used to provide a hierarchical association of an attribute.  URIs are commonly used in XML to uniquely identify a schema and are commonly confused with URLs due to their similarity, however a URI does not need to be a reachable networked location.
• IP Address
  IP address of the certified entity
• Registered ID
  An object identifier (OID) that can be used to identify the certified entity
• Other Name
  Yet another reference to extend the naming capability, use of this allows specification of anything available in the OTHER-NAME information object class

Certificate (Key) Usage Validation

In addition to validating the identity of the certificate holder an application may validate the purpose that the certificate is authorized for to ensure it is valid for its current use.  This validation is what prevents any non-CA certificate from acting as a certification authority and issuing certificates.  Key usage can be specified in either the "Key Usage"  or "Extended Key Usage" attribute based on the validation requirements of the application.

The "Key Usage" field offers generic purpose validation based on the way an asymmetric key pair may be used as part of a PKI.  This is a multivariate field that may consist of zero or more of the following uses:

• DigitalSignature
  The public key may be used to verify digital signatures for integrity purposes
• Non-Repudiation (later named contentCommitment)
  The public key may be used to verify digital signatures to prevent false denial of an action (i.e. to identify falsehood in a claim that an action did not occur).  The key difference between this use and the "Digital Signature" use is the validation of other signed elements (ex: time or other identifying elements that may not be listed in the certificate).  An example of this would be using S\MIME to digitally sign an e-mail
• Key Encipherment
  The public key may be used to encrypt keys or other security information.  An example of this would be SSL session key negotiation where the public key on the certificate from a Web server is used to encrypt a symmetric key to be shared to establish a secure channel between a computer and the server (the symmetric key is encrypted with the public key which can then only be decrypted by the matching private key held by the server)
• Data Encipherment
  The public key may be used to encrypt information that does not fall into the category of keys or security information.
• Key Agreement
  The public key may be used to negotiate a key without encrypting the key itself.  An example of this would be if a series of keys were pre-populated and the application encrypted information to allow the distant end to choose which key to use.
• Certificate Signing (keyCertSign)
  The public key may be used to validate certificate signatures (only valid on CA certificates)
• CRLSigning
  The public key may be used to verify a CA’s signature on a certificate revocation list (CRL)
• Encipher Only
  The public key may only be used to encrypt data to be sent to another system.  This key usage is only valid when the Key Agreement usage is set.
• Decipher Only
  The public key may only be used to decrypt data sent from another system.  This key usage is only valid when the Key Agreement usage is set.

In some cases these basic key usages may not be enough to identify a very specific or important use of the public key.  To address this need, the X.509 standard provides an additional field called Extended Key Usage (EKU).  Values for the EKU field are defined in a number of different RFCs.  Some examples of extended key usages include:

• Smart card logon
• OCSP signing certificates
• E-mail digital signature
• Certificate Revocation List (CRL) signing
• Time stamping
• Code signing
• Transport Layer Security (TLS) clients or servers

Certificate Chaining and Trust Validation

Another important part of validating a certificate is ensuring that it chains to a trusted root CA.  As discussed in my post on the X.509 certificate, any version 3 certificate signed by a certification authority should have at least one entry under the "Authority Information Access" pointing clients towards a location where they can obtain the certificate of the signing CA to validate the relationship.  This path should be available to all clients that may need to validate certificates issued by or chaining to the CA.  This concept is important to note when renewing the key pair on a CA since this is commonly done at around 50% of the CA's validity period meaning that certificates will need to access this path after key renewal occurs.  When a key pair is renewed on a CA the new certificate should not use the same path as the original certificate unless the private key for the CA and the authority key identifier (AKI) are not changed as part of the renewal.

Authority Key Identifier \ Subject Key Identifier Matching

Validity of a certificate chain is confirmed by retrieving the issuer's certificate (by default from the certificate's AIA path) and comparing the issuing certificate's subject key identifier (SKI) entry with the issued certificate's AKI entry.  As discussed in part 2 of this series, the SKI is populated with one of three values: the serial number of the certificate, a unique ID assigned by the signing CA, or any manner of identification listed as part of the GeneralName data type.  When a CA issues a certificate the signing certificate's SKI is imprinted as the issued certificate's AKI prior to being signed thus asserting the relationship.

Retrieving the Signing Certificate

To validate a certificate chain, the validating client must have access to every certificate up to and including the root CA.  By default, the client will try to use the certificate's AIA path unless the issuer's certificate is published to the client's intermediate certification authorities (SubCA) store.  Windows and Active Directory provide a number of ways to publish these certificates which will be discussed below.

The Authority Information Access Field

Once a certificate is issued the AIA path cannot be changed without reissue, therefore the location used to publish these certificates must be thoroughly thought out.  The AIA field allows for either HTTP or LDAP paths to provide flexibility in publishing locations.  By default, an Active Directory Certificate Services (ADCS) enterprise CA will publish its certificate to the Active Directory configuration partition which is automatically replicated to all domain controllers in the forest.  This provides site awareness and resiliency, however this path is best suited for internal use only since its path is likely inaccessible to external clients and can reveal information about your forest.

The alternative is to present the AIA path using HTTP, a more common and Internet-friendly means of distribution.  When using HTTP ensure that the web servers publishing the AIA path are highly available and scalable to handle requests from every client that may need to validate a certificate issued by the CA.

Some important considerations when deciding on the number and location of AIA paths include:

• Ensure the path is accessible to all clients in all reasonable situations
  Lack of a signing certificate will break the validating client's ability to chain to a trusted root CA and therefore will likely result in failed validation
• Be cautious about exposing internal configurations
  Although LDAP is a great option for providing availability and distribution, understand that listing an Active Directory path as the AIA path for a certificate will result in that path being hard-coded into every certificate signed by a CA
• Order AIA paths based on accessibility to validating clients
  Clients will try AIA paths in order, therefore it is ideal to list these paths in the order that provides the fastest access to clients

The Intermediate Certification Authorities Store

To reduce the number of connections to an AIA publishing point and increase resiliency of certificate validation it is sometimes ideal to install CA certificates to the Intermediate Certification Authorities (SubCA) store of validating clients.  Use of the SubCA store ensures that certificate validation continues without error when the AIA path written to the certificate becomes inaccessible.  As a side benefit, certificates published to clients provide additional configuration options to include configuration of cross-signing certificates, OCSP server address, extended validation options, and purpose limitation through the certificates snap-in or through Group Policy.

The Trusted Root Certification Authorities Store

 Since root CAs do not have an issuer their certificate will not have all of the information available used to validate other types of certificates (i.e. issuer, AKI, CDP, AIA).  Because of this, to establish trust with a root CA it must be installed in the trusted root certification authorities container (RootCA).  For a certificate to be considered valid the last CA in the chain must be installed in this container.  Like the SubCA store, the RootCA store can be populated locally, through Group Policy, or through Active Directory configuration.

Checking for Certificate Revocation

Issues with revocation checking services is probably one of the most common causes of PKI failure.  Since PKI is a security service many authentication applications will treat a lack of valid revocation information the same as if the certificate were revoked.  Since certificates are commonly issued for multiple years, the risk of compromise is significantly higher than a Kerberos ticket (5 minutes) or even a ticket granting ticket (10 hours).  As such, it is important to provide reliable revocation services for these credentials.  Since these revocation methods were covered thoroughly in a previous blog entry, this post will focus solely on client interactions with respect to revocation checking.

A few things to consider when designing revocation services:

• A client will accept the first valid response from a revocation provider
  It is ideal to order revocation providers based on locality and service performance.  Also, an expired Certificate Revocation List (CRL) counts as a valid response and commonly results in the certificate being treated as revoked.
• OCSP is significantly faster and more efficient than CRL checking
  Whenever possible, leverage OCSP services rather than CRL for PKI deployments of scale.
• Provide a valid CRL publishing location even if you are running Windows Vista+
  Not every application supports OCSP and the revocation check is not always performed by Windows (i.e Java applications).  Also, Windows XP and prior operating systems do not support OCSP.  Because of this, it is important to provide a CRL download point to support these situations.

Online Certificate Status Protocol (OCSP)

Since Windows Vista and Certificate API: Next Generation (CAPI-NG), Online Certificate Status Protocol (OCSP) has been the preferred method to determine the revocation status when available.  In addition to supporting OCSP addresses listed in the certificate's AIA, Windows Vista and later also provide the ability to specify alternate OCSP servers through Group Policy or the certificates MMC snap-in.  When configured, these addresses are attempted in order prior to trying any addresses listed in the certificate and can be use to provide locality-based services and additional redundancy.  On the same tab with the OCSP responders is the option to disable CRL checking altogether; this is not recommended as it may result in denial of service should OCSP services be unavailable.  If OCSP addresses are not configured, Windows will try the OCSP address listed in the certificate's AIA field if one exists.

Certificate Revocation Lists (CRL)

In the event that OCSP services are not available, if a non-OCSP aware software package is validating revocation status, or Windows XP or prior is in use, revocation  the operating system will begin trying paths listed in the CDP field of the certificate in the order provided from top to bottom.  The order of CRL distribution points is an important consideration when configuring a CA because clients may experience performance issues or denial of service due to inaccessible CDP paths.  In addition, be cautious when using internal addresses on publically available certificates as it may expose internal design information.

A major concern when using CRLs pertains to their potential size.  When large amounts of certificate revocations occur on a CA a CRL can grow very large if not partitioned and may result in clients experiencing timeouts when reading these large files.  Additionally, a larger CRL will take more resources to validate a certificate.  Please note the upcoming section on URL retrieval timeouts when considering the design of your revocation strategy.

Another important consideration when designing a CRL revocation check strategy is ensuring the freshness of the published CRL.  In some applications (such as smart card logon), inability to retrieve a valid CRL causes the certificate to be treated as if it were revoked.

Final Notes 

URL Retrieval Timeouts

An important note when considering AIA and CDP paths is the client's URL retrieval timeout limits.  In Windows XP (and I am assuming this hasn't changed) clients are allowed a 15 second period to download the certificate from an AIA path or a CRL from a CDP.  Within these 15 seconds, the first 10 seconds are allotted to the first path with every subsequent path being allowed 50% of the remaining time of its predecessor (ref: http://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx#CRL_Retrieval_Timeout_Thresholds).  This means that if a client may take more than 10 seconds to download the content they will be unable to perform the revocation check on any path.

For internal clients with large CRLs or slow links this setting is manageable through registry modification:

• URL Retrieval Timeout
  Registry Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config 
  Type: REG_DWORD
  Name: ChainUrlRetrievalTimeoutMilliseconds
  Default: Not set, effective setting is 15000 (15 seconds)
  Range: 1 - 65535
  Purpose: Configures the total amount of time (in milliseconds) that a client will allot for retrieving a single certificate's AIA or CDP path
• Aggregate URL Retrieval Timeout
  Registry Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
  Type: REG_DWORD
  Name: ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds
  Default: Not set, effective setting is 20000 (20 seconds)
  Range: 1-65535
  Purpose: Defines the maximum amount of time allotted to all URL downloads of a type.
• Maximum AIA URL Count
  Registry Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
  Type: REG_DWORD
  Name: MaxAIAUrlCountInCert
  Default: Not set, effective setting is 5
  Range: 1-65535
  Purpose: Defines the maximum number of AIA paths retrieved when validating a certificate chain

Custom CAPI Revocation Providers

This entry covers the way that Windows performs certificate validation, however some environments use custom revocation providers which may modify this behavior.  If this software is in use, please refer to their documentation for information on the certificate validation process.

Certificate revocation information is available in various forms; I will cover these in an evolutionary manner starting with the Certificate Revocation List (CRL).

Certificate Revocation List (CRL)

The CRL, originally defined in RFC 1422, is a flat file containing the serial numbers of certificates revoked by the signing certificate authority (CA).  Two versions of the CRL format exist; however, version 1 is unlikely to be found today.

CRL version 1

Originally defined in the 1988 ITU standard for PKI (section 10.2.6), version 1 of the CRL format was suitable for directory services use only.  In its initial version, the CRL was expected to exist in a predictable location in directory services and provided two multivariate values: certificateRevocationList and authorityRevocationList.

• Certificate Revocation List
  An array of certificate serial numbers corresponding to certificates revoked by a certificate authority.  Each entry is formatted as follows:
• Signature
  A digital signature to prevent unauthorized tamper of the CR
• Issuer
  The name of the CRL issue
• Last Update
  The UTC time of the CRL update
• Revoked Certificates
  A signed certificate revocation entry containing the certificate issuer, serial number, and revocation date
• Authority Revocation List
  Though rarely implemented, the Authority Revocation List (ARL) provides a revocation mechanism for trusted certificate authorities.  This functionality is effectively replaced through adding compromised root CAs to the untrusted certificate authorities container in Windows.

This simple format was modified in 1993 prior to being formally implemented in RFC 1422 along with the first version of the X.509 certificate (http://tools.ietf.org/html/rfc1422, section 3.5).

CRL version 2

As the possibilities associated with PKI were realized, it became apparent that version 1 of the CRL was insufficient for the wide array of purposes it could serve.  In response, CRL version 2 was developed and published along with the new X.509 v3 certificate standard in RFC 2459 (http://tools.ietf.org/html/rfc2459, section 5).  The format added the following fields:

• Version
  This field is used to denote format used for the CRL
• Revoked Certificates {crlEntryExtension}
  The optional crlEntryExtension attribute was added to the revokedCertificates type to allow the CA to note reason codes and revocation dates associated with certificate revocation entries.  This class contains the following fields:
  • Reason Code
    The reason code is an integer value noting the reason why the certificate was revoked
  • Hold Instruction Code
    This feature shows that a CA is now able to place a certificate on hold, a state whereby the certificate is to be treated as revoked, however not necessarily permanent.  One interesting feature of this field is the ability to have the validating entity contact the issuer if the certificate is encountered.
  • Invalidity Date
    This is the date that the certificate was deemed invalid
  • Certificate Issuer
    This is a very important field noting the issuer of the revoked certificate by its subject.  If this field is empty it is assumed that the revoking entity was the same as the CRL issuer.
• CRL Extensions
  Version 2 of the CRL format was improved much in the same way as version 3 of the X.509 certificate.  This field holds values defined as extensions in RFC 5280, the same RFC used to define certificate extensions.  A discussion of some of the extensions available for use is available in part 2 of the PKI series.  Extensions designed specifically for use with CRLs are discussed below.

CRL Extensions

Version 2 of the CRL added a few extensions specifically designed for improving validation capabilities.  Some of these extensions include the following:

• Authority Key Identifier
  Like the X.509 certificate, the authority key identifier is a string value used to uniquely identify the key pair used to sign the CRL.  This value is most commonly populated with a hash of the public key.
• Issuer Alternative Name
  A CA administrator can use the issuer alternative name to specify identities other than the subject that the signing CA may be known by.  Essentially, this is the same as the X.509 subject alternative name field except applying to the issuer rather than the certified asset.
• CRL Number
  CRL number is a serial number associated with the current CRL.  This number should be sequential and incremented by one with every new CRL published.
• Delta CRL Indicator
  The delta CRL is a differential revocation list designed to improve performance of revocation checking, especially in the instance of large or fast-growing revocation lists.  This functionality is discussed below.
• Issuing Distribution Point
  This field identifies where the CRL is published for consumption and should match the CRL distribution point (CDP) field of the associated certificate.  This path must be either HTTP or LDAP.

Delta CRL

Version 2 of the CRL improved revocation checking through implementing the concept of a delta CRL.  Bandwidth can become an issue when revocation lists change frequently or grow lengthy with revoked certificates.  To address this concern the standard created the ability to use delta CRLs; differential revocation lists published on a more regular basis than the CRL.

Without delta CRLs, a client must download potentially large revocation lists (100 MB is possible) every time the CRL expires.  This causes the CA administrator to need to choose between bandwidth and timely revocation information (clients will not need to obtain a new CRL until the old one expires, therefore it may take weeks before the revoked credential is treated as such by clients).

The delta CRL was designed to alleviate these concerns by providing a smaller differential CRL containing all certificates revoked since the publishing of the main CRL that could be published more regularly and required less bandwidth to download.

An important note regarding the use of delta CRLs is that a valid copy of both the main CRL and the delta CRL must be available to perform a successful revocation check.  Because of this, an empty delta CRL must be published whenever a new CRL is published.  By default, in a Windows CA the delta CRL is published with the same name as the CRL with a “+” appended.

Online Certificate Status Protocol (OCSP)

Despite improvements realized from the use of delta CRLs, the revocation process was still bandwidth and resource intensive.  Clients wishing to validate the revocation status of a certificate needed to download one or two files (CRL and an optional delta CRL), load these potentially large files into memory, perform a signature and trust verification, and finally search them for a serial number.  Though this may not sound terribly resource intensive consider a situation such as smart card login for a domain controller.  Due to the security implications associated with domain authentication, revocation information is sought at every authentication attempt.  If multiple CAs provide user certificates for logon purposes each will have their own CRLs and delta CRLs.  This scenario compounded with the morning logon rush and large (50+ MB) revocation lists and performance will quickly degrade.

In 1999, Entrust’s RFC for OCSP (http://www.ietf.org/rfc/rfc2560.txt) was published in an effort to solve all of these issues.  The vehicle used to perform revocation checks using OCSP is defined loosely (no transport mechanism is mandated per RFC), however almost all implementations of OCSP use HTTP or HTTPS.

OCSP Request

An OCSP request is formatted using ASN.1 syntax with DER encoding in alignment with the formatting of most other PKI communication.  The basic format of the OCSP request is as follows:

• Version
  The version of the OCSP protocol used
• Requestor Name
  An optional string value representing the identity of the requestor
• Request List
  A multivariate attribute containing one or more certificates to validate.  This is an important improvement that allows a single request to validate multiple certificates.  Individual requests are sent using a hash of the issuer name, a hash of the issuer’s public key, and the serial number of the certificate to be validated.

Optionally, the entire request can be digitally signed to prove the identity of the owner as well as the integrity of the message (without this, it is possible to use a man-in-the-middle attack to modify the request in-transit and change the certificates being validated thus damaging the integrity of the system).

OCSP Response

Once the OCSP responder has accepted the request, it searches the revocation information it has stored and generates an individual response for each revocation request returned as an array of responses.  In addition to these responses, the responder has the ability to provide response status codes.  Per RFC 2560 the approved response codes are:

• (0) Successful
• (1) Malformed Request
• (2) Internal Error
• (3) Try Later
• (5) Signature is Required (and wasn’t provided as part of the request)
• (6) Unauthorized

Each certificate revocation request entry is provided an individual response (for example, if four certificates were sent for validation the response will contain four OCSP response entries).  Each individual entry is digitally signed and is listed as either good, revoked, or unknown along with the last and next update of revocation information.  If the certificate is revoked, the revocation time is provided along with (optionally) the reason for revocation.

OCSP Responder Certificates

Right about now I’m sure some of the security geeks out there are thinking of all of the scenarios that could result from obtaining a trusted certificate for OCSP purposes.  To address the potential issue whereby an attacker could trick a victim into trusting revocation information through using an OCSP responder certificate from a well-known trusted certification authority the standard mandates that the OCSP responder certificate must have been issued from the CA it is answering on behalf of (RFC 2560 section 4.2.2.2).  This is important from an implementation perspective as it means one cannot just stand up an OCSP responder and feed it CRLs from CAs they do not own.  For organizations with heavy revocation checks against organizationally external CAs this likely means reliance on WAN links for activities that require positive revocation responses (i.e. smart card logon).  To solve this issue, some OCSP responder vendors have developed systems whereby OCSP responses are pre-signed and downloaded to on-site OCSP responder instances thereby alleviating reliance on the WAN.  In addition, Microsoft provides an option on Windows 7 \ Windows Server 2008 R2 and later clients to allow the OCSP responder to use any trusted OCSP responder certificate for a CA.

Now a chicken-and-the-egg issue arises: if the OCSP responder certificate is issued by the CA and also responds on behalf of the CA how do we obtain revocation information for that certificate?  The answer here: we don’t.  This means that the compromise of an OCSP responder certificate is a critical security breach.  To address this issue, OCSP responder certificates should be issued with a very short lifespan.  By default, the Active Directory certificate template used for OCSP specifies a validity period of two weeks.

Nonce

One question that tends to arise when customers  configure OCSP is an option called “include nonce”.  According to RFC 2560 “The nonce cryptographically binds a request and a response to prevent replay attacks”; an abstract term that leads most to only becoming more confused, enabling nonce, then potentially experiencing revocation outages.  The nonce extension prevents the OCSP responder from using a cached revocation response.

Using the nonce extension forces an administrator to decide that the integrity of the revocation response is so important that it is worth risking the availability thereof.  Using this option prevents use of the previously-mentioned OCSP response caching systems, will increase the CPU utilization on the OCSP responder, and increase the time it takes to receive a revocation response. 

If the nonce extension is configured and the OCSP responder is unable (either through configuration or lack of an OCSP responder certificate) to provide this capability it will reject the request with an “unauthorized” error.

Locating an OCSP Responder

OCSP responder addresses can be stamped as part of the certificate’s properties; however, they are not where most would expect to find it.  If a CA has an OCSP responder available, it can stamp the address of the OCSP responder in the Authority Information Access extension (not the CRL Distribution Point).

In some cases, organizations may add an OCSP responder after implementing PKI or offer an on-site OCSP responder to improve performance and decrease WAN utilization.  For these situations, Microsoft provides the option to configure OCSP addresses through group policy (Windows Vista or later).  OCSP responder information is configured on a per-CA basis in the certificate store, whether in Group Policy or locally.  For detailed information on how to configure an OCSP responder with Group Policy please refer to http://technet.microsoft.com/en-us/library/ee619786(v=WS.10).aspx.

Last, if your organization has down-level (Windows XP \Server 2003 R2 or prior) you may need to rely on a third-party OCSP responder client to provide this functionality.

In most cases key pair generation occurs as part of a certificate request process (without a certificate request the asset can only be self-signed and thus will not be trusted by external entities by default).  As part of the certificate request the requesting user or computer will specify a series of attributes it would like to appear on the certificate.  These attributes can be changed by the certification authority prior to issuance of the certificate (depending on the CA software being used) based on the template, issuance policies, etc.  All of this information is then digitally signed by the new private key to prove ownership and packaged into a ASN.1 DER-encoded certificate request following either Public Key Cryptography Standard (PKCS) #10 (http://www.rsa.com/rsalabs/node.asp?id=2132) a.k.a. RFC 2986 (http://tools.ietf.org/html/rfc2986) or Certificate Management Messages over CMS (CMC) request (http://www.ietf.org/rfc/rfc2797.txt).

Once the request is generated it can be transmitted safely to the certification authority in a number of manners based on the system used and its available capabilities ranging from a completely manual submission to a completely automated enrollment when using Windows Server 2003 or later CA's and domain membership (this topic will be covered in a later post).  Regardless of how the request is transmitted to the CA it will result in a pending certificate request requiring some form of authentication and authorization (which may be automated) and is not governed by the X.509 standard.  In many cases certificates are issued based on templates, a capability defined in RFC 4212 (http://www.ietf.org/rfc/rfc4212.txt).  These templates enable standardization of the format used for a given certificate and, in the case of Microsoft Windows CAs, can be used to determine issuance policies.

At this time, the administrators operating the CA have the ability to review and optionally modify (based on the CA platform used) the request to fit policy.  Once the organization operating the CA has sufficiently determined the authenticity of the request and its authorization the CA administrator can approve the request which will cause the CA to convert the request into an X.509 certificate.  At this time the certificate will contain the public key, a validity period determined by the CA, the location(s) where clients can access the CA's public key (called the Authority Information Access, or AIA), location(s) where revocation information will be published (called the Certificate Revocation List (CRL) Distribution Point, or CDP), a hash of the CA's private key (called the Authority Key Identifier), as well as a number of other parameters that can be optionally configured on the CA (for more information on this please see the previous post in this series, http://blogs.technet.com/b/option_explicit/archive/2012/04/09/pki-series-part-2-certificates-and-the-x.509-standard.aspx).  The authenticity is then established when the CA uses its private key to digitally sign this information thus preventing unauthorized modification.

Using a Microsoft Certification Authority

Microsoft provides many benefits when using the Active Directory Certificate Services (ADCS) certification authority role, especially when configured as an enterprise certification authority.  For the purposes of this post we will limit the discussion of these benefits to only those facilitating enrollment and will not cover topics such as certificate management, template management, or other CA-centric tasks (these will be covered in a later post).

Organizations leveraging an ADCS enterprise CA are able to use features such as certificate auto-enrollment (or for Windows 2000 workstations Automatic Certificate Request) to simplify the process of certificate issuance.  These features allow users and computers to leverage their Active Directory credentials to request certificates from an enterprise CA.

Automatic Certificate Request Settings (ACRS)

Automatic Certificate Request Settings (ACRS) was developed as a means to automatically issue computer certificates on computers running Windows 2000 or later.  This feature enables these computers to automatically enroll themselves for a computer certificate from a specified enterprise CA.

ACRS is configured through computer group policy and will only appear when editing a domain policy (these settings will not be displayed if you are editing your local computer policy) and are at the following location: "Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Automatic Certificate Request".  Certificates used for ACRS must be based on an Active Directory certificate template which is assignable to computer objects (this method cannot be used to enroll user certificates) and can only be based on a v1 template (listed as a "Windows 2000" template in Windows Server 2008 R2 and prior or as schema version 1 on Windows Server 8 beta).

Certificate Auto-Enrollment

Auto-enrollment is an evolution of ACRS that began shipping with Windows 2003.  Auto-enrollment provides both users and computers the ability to participate in automatic certificate enrollment.  Client computers participating in auto-enrollment must use at least Windows 2003 or Windows XP and require an enterprise CA running one of the following operating systems:

• Windows 2003 Enterprise or Datacenter
• Windows 2003 R2 Enterprise or Datacenter
• Windows 2008 Enterprise or Datacenter
• Windows 2008 R2 Standard, Enterprise, or Datacenter

To use auto-enrollment the user or computer must be allowed both enroll and autoenroll permissions on the Active Directory certificate template.  In addition, the enrolling user or computer must be configured to use auto-enrollment through group policy (note: computer configuration only applies to the computer's automatic enrollment ability and the user's configuration only applies to the user's automaitc enrollment; one does not configure both).

Auto-enrollment requires a certificate template version of at least 2 (listed as "Windows 2003" in Windows 2008 R2 and prior, schema version 2 in Windows Server 8 beta); the autoenroll permission isn't even available on v1 templates.

ADCS Web Enrollment

Microsoft provides Web enrollment as a role feature for ADCS to simplify user certificate enrollment processes (in previous versions users were allowed to enroll certificates on behalf of computers, however this is no longer available).  In its current version (Windows Server 2008+) Web enrollment allows users to request certificates based on v1 and v2 certificate templates and, based upon issuance policies assigned to those templates, can automatically issue certificates based on provided domain authentication.

Certificate Enrollment Web Services (CES) \ Certificate Enrollment Policy Web Services (CEP)

A new feature introduced with Windows Server 2008 R2 is the ability to manage certificate enrollment using Web services using a combination of the Certificate Enrollment Web Services (CES) and Certificate Enrollment Policy Web Services (CEP) role features (under the ADCS role).  These Web services enable administrators to configure client computers to manage certificates without RPC access to the certification authority (a major manageability improvement when dealing with firewalls).  Use of this feature requires at least Windows Vista or Windows Server 2008 certificate clients.

Microsoft Simple Certificate Enrollment Protocol (MSCEP) \ Microsoft Network Device Enrollment Services (NDES)

In order to support Cisco System's Simple Certificate Enrollment Protocol (SCEP) (http://www.cisco.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm) Microsoft provides two different solutions based on what version of Windows is running on the server performing certificate enrollment;  Microsoft Simple Certificate Enrollment Protocol (MSCEP) in Windows Server 2003 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=2178) and Network Device Enrollment Services (NDES) role service in Windows Server 2008 (http://technet.microsoft.com/en-us/library/ff955645(v=ws.10).aspx).

Many new devices are requiring certificates to authenticate to corporate resources in order to obtain access to resources such as wireless networks.  Some of these devices have chosen to leverage the SCEP protocol to request their certificate due to its inherent simplicity.  SCEP is essentially a simple Web service that can provide a device a certificate in as few as four exchanges (client requests SCEP server's certificate, SCEP server sends certificate, client requests certificate from SCEP server, server provides certificate) when authentication is not used; Even when the SCEP server requires authentication only a few additional packets are required to complete the transaction.

How to Perform a Certificate Request using the Windows GUI \ CLI

Microsoft Windows offers a number of ways to generate a certificate request.  In addition to the following methods, many applications (such as IIS and Exchange) provide interfaces to request certificates from the operating system to simplify the process and to ensure that all required attributes and OIDs are resident in the request.  To simplify this post, we will cover three of the most common ways to generate certificates; the MMC snap-in, certreq.exe, and Internet Information Services (IIS).

Request a Certificate using the Certificates MMC Snap-In with an Enrollment Policy

If your environment is configured with an enterprise certification authority (or if you are requesting a certificate using Certificat Enrollment Web Service (CES) feature of Windows 2008 R2) you may have the ability to leverage the enrollment policy to handle your certificate request.  Enrollment policies are essentially instructions for how your computer can request certificates from an enterprise certification authority.

1. Open the Microsoft Management Console (MMC).
2. Click the File drop-down menu and select "Add / Remove Snap-in...".
3. Double-click the "Certificates" snap-in and select the principal you want to request a certificate for (the current user, a service account, or the computer's account) and click the "Next >" or "Finish" button.
1. If you selected service account or computer account choose the user you are requesting a certificate for (you cannot perform any private key management requests for remote computers) and click the "Finish" button.
4. Click the "OK" button on the "Add or Remove Snap-ins" dialogue.
5. Expand the newly-added "Certificates" snap-in.
6. Right-click the "Personal" store (it will appear as a folder), select "All Tasks >", then "Request New Certificate...".
7. Click the "Next >" button on the "Before You Begin" dialogue.
8. If you are requesting a certificate based on a published template choose the appropriate enrollment policy and click the "Next" button.  If you need to perform a custom request (i.e. a request where you will need to specify a different enrollment policy than is configured) you can click the "Add New" option under "Custom Request" and specify the enrollment policy server's information.
9. Choose the template for the certificate you wish to request and click "Enroll".  Note that this screen will only display certificate types that you are allowed to enroll for; selecting the "show all templates" option will display all available templates.
1. Some certificates will require additional information prior to requesting them.  These can be identified by the caution symbol beneath the template and to the left of to the link to provide the additional information.
10. Based on the configuration of the certificate template the certificate will either be automatically issued to you or be submitted for authorization by a CA manager.  The certificate will be automatically downloaded and installed once the request is complete if using the Active Directory enrollment policy.  If the certificate was requested using CES from an external organization the certificate can also be installed manually by importing it into the certified entity's personal store.

Request a Certificate using the Certificates MMC Snap-In without an Enrollment Policy (called an offline request)

If you are working with a stand-alone or external certification authority you may need to process your request through submission of a PKCS #10 or CMC request.

1. Open the Microsoft Management Console (MMC).
2. Click the File drop-down menu and select "Add / Remove Snap-in...".
3. Double-click the "Certificates" snap-in and select the principal you want to request a certificate for (the current user, a service account, or the computer's account) and click the "Next >" or "Finish" button.
1. If you selected service account or computer account choose the user you are requesting a certificate for (you cannot perform any private key management requests for remote computers) and click the "Finish" button.
4. Click the "OK" button on the "Add or Remove Snap-ins" dialogue.
5. Expand the newly-added "Certificates" snap-in.
6. Right-click the "Personal" store (it will appear as a folder), select "All Tasks >", then "Advanced Operations >", then "Create Custom Request...".
7. Select "Proceed without enrollment policy" under the "Custom Request" header and click the "Next" button.
8. Choose the template (CNG (not supported on all applications as of this writing) or Legacy Key) from the drop-down menu and the request format (CMC or PKCS #10) and click the "Next" button.
9. Click the arrow next to "Details" under the "Custom Request" header and click the "Properties" button.
10. Fill out the certificate properties for the associated request (an explanation of these properties are available in the previous post).  Once complete click the "OK" button.
11. Click the "Next" button on the "Certificate Information" window.
12. Choose where you would like to save the resulting request file and the format to save it in and click the "Finish" button.
13. Provide this file to the certification authority to submit the request (software implementations may vary).
14. Once the certificate request is approved, the resulting certificate file can be imported into the requesting entity's personal store to join the certificate with its associated private key.

Using certreq.exe

 For those fond of command line interfaces and .inf files Microsoft has provided certreq.exe.  Using certreq.exe is simple, however the associated .inf file can be complex.  Formatting required for the .inf file can be found at the following location: http://technet.microsoft.com/en-us/library/cc736326(v=WS.10).aspx. 

certreq.exe -new

Generating a new certificate request can be done by running the "certreq.exe -new {requestFileOutputPath}" command and either specifying the requested attributes as switches or providing an .inf file with all of the requested attributes for the new certificate.

certreq.exe -submit

Once a request has been generated it can be easily sent to a CA configured by an enrollment policy using the "certreq.exe -submit {requestFilePath}" switch.

certreq.exe -retrieve

If a certificate has been approved by an enterprise CA it can be retrieved using "certreq.exe -retrieve {requestID}".  This command will retrieve the signed certificate from the CA and allow you to save it to your system.

certreq.exe -accept

To complete a request using certreq.exe you can use the "certreq.exe -accept" switch to install the new certificate and associate it with the private key. 

Using Internet Information Services (IIS)

 A common way to request secure sockets layer (SSL) certificates is through the built-in interfaces provided in IIS.  The following are steps required to perform the certificate request (source: http://technet.microsoft.com/en-us/library/cc732906(v=WS.10).aspx)

1. Open IIS Manager and navigate to the level you want to manage. For information about opening IIS Manager, see Open IIS Manager (IIS 7). For information about navigating to locations in the UI, see Navigation in IIS Manager (IIS 7).
2. In Features View, double-click Server Certificates.
3. In the Actions pane, click Create Certificate Request.
4. On the Distinguished Name Properties page of the Request Certificate Wizard, type the following information, and then click Next.
1. In the Common name text box, type a name for the certificate.
2. In the Organization text box, type the name of the organization in which the certificate will be used.
3. In the Organizational unit text box, type the name of the organizational unit in the organization in which the certificate will be used.
4. In the City/locality text box, type the unabbreviated name of the city or locality where your organization or organizational unit is located.
5. In the State/province text box, type the unabbreviated name of the state or province where your organization or organizational unit is located.
6. In the Country/region text box, type the name of the country or region where your organization or organizational unit is located.
5. On the Cryptographic Service Provider Properties page, select either Microsoft RSA SChannel Cryptographic Provider or Microsoft DH SChannel Cryptographic Provider from the Cryptographic service provider drop-down list. By default, IIS 7 uses the Microsoft RSA SChannel Cryptographic Provider.
6. In the Bit length drop-down list, select a bit length that can be used by the provider. By default, the RSA SChannel provider uses a bit length of 1024. The DH SChannel provider uses a bit length of 512. A longer bit length is more secure, but it can affect performance.
7. Click Next.
8. On the File Name page, type a file name in the Specify a file name for the certificate request text box, or click the browse button (…) to locate a file, and then click Finish.
9. Send the certificate request to a public CA. 

How to Perform a Certificate Request using a Script

For all of the systems administrators wishing to automate this effort somewhat I will provide two script examples on how to request an X.509 certificate, one in VBScript and the other a custom PowerShell cmdlet that I created.  Before getting into the code I will take a moment to cover the object used in requesting certificates, CEnroll (http://msdn.microsoft.com/en-us/library/windows/desktop/aa376007(v=vs.85).aspx).

How to Establish the Relationship Programmatically

Now, for my code monkey readers some sample code thanks to MSDN.  In addition, I will provide a non-developer translation for the sysadmins interested in how things work behind the scenes. 

Generating and Submitting a Certificate Request in C++

The following source code was copied from the following MSDN post  (http://msdn.microsoft.com/en-us/library/windows/desktop/aa387670(v=vs.85).aspx).  Please note that this code uses Windows XP \ Server 2003 R2 and prior methods.

So, what is PKI?

PKI is a system that leverages certificates and asymmetric cryptography to exchange encryption keys paired with trustworthy attributes through use of a hierarchical trust system and revocation infrastructure.  The entire basis of PKI surrounds the certificate, a document containing the public key of the asset being certified (the one holding the corresponding private key) as well as a number of attributes about that system digitally signed by (in most cases) a certification authority (CA) that chains up to a trusted source (commonly a root CA).  The attributes on these certificates are used to prove different aspects about the user or computer with the associated private key to include:

• A subject (or subject alternative name) which can be used to match an identity associated with a certified asset (i.e. DNS name, user name, e-mail address, etc.)
• A validity period for the certificate
• A location where revocation information for the certificate could be found
• A location where the certificate issuer's certificate can be found to validate the relationship

The X.509 Certificate

The basis of any PKI is the X.509 certificate.  This certificate contains a number of values used to identify the certified entity and prove its validity and trust to the remote end. 

History of the X.509 Standard

PKI is governed by a the X.509 standard published by the International Telecommunications Union (ITU-T) (http://www.itu.int/ITU-T/) as part of the X.500 series of standards governing directory services.  Those of you familiar with Active Directory or Exchange will be familiar with X.500, the standard responsible for LDAP, the Directory Information Tree (DIT), Directory Systems Agent (DSA), and a number of other Active Directory foundations (http://www.itu.int/rec/T-REC-X.500-200811-I).

The X.509 standard is one of the more active X.500 standards undergoing (as of this writing) a total of 20 revisions since its initial publish in November of 1988.  This high level of activity speaks to the level of evolution in the standard driven by its widespread use.  The initial X.509 standard was labeled as  "X.509 : The Directory - Authentication framework" , however this was changed to "X.509 : Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks" in its fourth revision in March of 2000.  This name change reflects the change in use of the X.509 standard due to its widespread use for purposes other than directory authentication.

In the original X.509 standard PKI is referred to as "strong authentication" leveraging a family of cryptographic systems known as Public Key Cryptographic Systems (PKCS).  The standard does not necessitate a specific encryption algorithm, but rather describes itself as a "framework... applicable to any suitable public key cryptosystem" which remains consistent in all subsequent versions of the X.509 standard (http://www.itu.int/rec/T-REC-X.509-198811-S).  This is an important note since it demonstrates that PKI is not a specific cryptographic algorithm, but rather a means to use an asymmetric algorithm of the user's choosing to prove a set of meta data which enables identification and trust.

Certificate Versions and Attributes

 X.509 certificates are currently in their third format since the original ITU specification.  Each subsequent version of the certificate was designed to be backwards compatible with any prior versions and thus will contain all attributes from the prior version.  Due to this backwards-compatibility attributes will be provided in association with the version in which they were established.  In cases where the purpose or use of the attribute changed over time the change will be noted in the initial declaration of the attribute.

Version 1 (RFC 1422 http://www.ietf.org/rfc/rfc1422)

Version 1 of the X.509 certificate standard was established in 1993 despite being originally established by the ITU in November of 1988.  At this time the focus of the standard was directory services authentication and did not include any mechanisms to obtain the public key or revocation information.  Fields on a version 1 certificate are as follows:

• Version Number
  The version number field denotes the version of the X.509 certificate.  Version 1 certificates have this value set to 0.
• Serial Number
  The unique serial number of the certificate assigned by the certification authority.  The size of the serial number (data size) should be consistent for all certificates issued by a certification authority.
• Signature and Signature Algorithm
  This field holds the digital signature from the issuing authority as well as the algorithm used to perform the signature.  This signature is what protects and proves the integrity of the attributes stored in the certificate.  The signature is verified using the public key of the issuing CA.
• Issuer Name
  The issuer name was, at this time, the distinguished name of the issuing CA used to uniquely identify the certifying authority for trust validation.  In version 2 of the X.509 standard they realized the rigidity of the standard and established an additional field, issuerUniqueIdentifier, which could be used in lieu of the distinguished name of the CA.
• Validity Period
  This field contains the start and end of the time period which the certificate will be valid written in coordinated universal time (UTCT) format based on Greenwich Mean Time (GMT).  In addition, it is recommended that the granularity of time used in this field be no more than a minute, however flexibility is permitted.
• Subject Name
  This field contains the X.500 Distinguished Name (DN) used to uniquely identify the object.  The intent in X.509 version 1 was to tie the entity to a location in a directory, however later modifications of this field now use it as a way to uniquely identify the principal that owns the certificate (for example, the DN does not need to be the same as an object's DN in Active Directory).  This modification started in X.509v2 (the subjectUniqueIdentifier field was established to allow the authenticating entity to use this field in the event that the DN was reassigned).  To allow additional flexibility, the subjectAlternativeName attribute became available in version 3 (discussed later in this post).
• Subject Public Key
  This field holds the public key of the subject as well as the algorithm identifier.

Version 2 (ITU-T Recommendation X.509, Nov 1993 http://www.itu.int/rec/T-REC-X.509-199311-S)

Version 2 of the X.509 certificate was very short-lived and rarely used.  In fact, the Internet Engineering Task Force (IETF) did not turn version 2 of the certificate into a RFC standard whatsoever.  The key change from X.509v1 to X.509v2 was the improved flexibility in identifying the issuer and the subject.  Fields added by the X.509v2 standard are the following:

• Issuer Unique Identifier
  The issuer unique identifier field allowed another (optional) means to uniquely identify the certification authority.

• Subject Unique Identifier
  As with the issuer unique identifier, the subject unique identifier was an optional field that could be used to provide a unique ID for the subject.  The explanation for this is to allow reassignment of a distinguished name while still maintaining the ability to uniquely identify the subject (see note 2 under section 8)

Version 3 (RFC 2549 http://tools.ietf.org/html/rfc2459)

Version 3 of the X.509 certificate is the most common format found today.  In this version of the certificate a single field was added that allows the extensibility required to support multiple applications and is likely the reason that this version is still in use today.

• Extensions
  The extensions field of a certificate is defined as a series of data type Extension.  Each extension has three parts:
• Extension ID (extnId)
  A value designed to hold an object identifier (or OID) which is used to uniquely identify the value that follows
• Critical
  Critical is a Boolean value with a default value of false.  If set to true, applications processing the certificate will be expected to validate the setting in order to ensure the identity of the certificate holder (in other words, the validation of the extension is critical to properly identifying the certificate holder).
• Extension Value (extnValue)
  This is a DER-encoded value formatted as specified by the extension type.  For example, if the extension ID was the OID associated with RFC822Name (commonly used to denote e-mail addresses) this value would hold the e-mail address.

Another important thing to note about this standard is the awareness of the upcoming century change.  Note 2 under section 8 specified that two-digit UTC year notations with a value of 00 to 49 would be treated as years 2000 – 2049 while two-digit year notations of 50 – 99 would denote 1950 – 1999.

Extensions (based on RFC 5280, May 2008 http://www.ietf.org/rfc/rfc5280.txt)

With the new capability came a set of new extensions.  At this time we will depart from the historical context behind these changes and focus on the fields and their purposes.

• Authority Key Identifier
  This field identifies the public key that can be used to verify the issuer of the certificate.  The authority key identifier field enables the use of distinct keys by the same certification authority (for example, in the event of a key renewal).  The three means to identify this key relationship are through the serial number of the issuer’s certificate, a unique ID established by the certification authority, or through use of any manner of identification listed as part of the GeneralName data type.  The GeneralName data type allows the use of any of the means provided by the Subject Alternative Name class.   Most commonly, the AKI is populated with a hash of the public key used by the issuing CA.  The important part of this field is that its value must match that of the subject key identifier on the issuing CA.
• Subject Key Identifier
  The subject key identifier is used to identify the current public key being certified.  It can be populated with any of the values available to the authority key identifier.
• Key Usage
  The key usage field is used to define the purposes that the public key can be used.  Values that can exist for key usage are:
  • DigitalSignature
    For verification of digital signatures
  • Non-Repudiation (later named contentCommitment)
    For verifying digital signatures used to prevent false denial of an action (i.e. to identify falsehood in a claim that an action did not occur)
  • Key Encipherment
    For enciphering keys or other security information
  • Data Encipherment
    For enciphering information that does not fall into the category of keys or security information
  • Key Agreement
    For use as a public key agreement key
  • Certificate Signing (keyCertSign)
    For verification of CA signatures on certificates
  • CRLSigning
    For verifying a CA’s signature on a certificate revocation list (CRL) (this topic will be covered in a later post)
  • Encipher Only
    For enciphering data during key agreement (requires the keyAgreement bit)
  • Decipher Only
    For deciphering data during key agreement (requires the keyAgreement bit)
• Extended Key Usage
  This field may be used in conjunction with or in replacement of the key usages specified above and allows for more specific controls over what purposes the certificate is valid for.  The following list identifies enhanced key usages defined by RFC 5280 (please note, there are many of these that exist and are not listed in the standard):
• TLS WWW server authentication
• TLS WWW client authentication
• Signing of executable code (code-signing)
• E-mail protection
• Time stamping
• OCSP signing
• Authority Information Access (AIA)
  The AIA field of a certificate is very important to validating the trust chain of a certificate.  This multivariate field contains one or more HTTP or LDAP paths to the signing CA's certificate.  This field must be reachable by the client to validate the signature of a certificate and trace a path to a trusted root CA.  In addition, this field may conain one or more URLs that point to Online Certificate Status Protocol (OCSP) servers to improve revocation checking performance.  OCSP will be covered in part 4 of the PKI series.
• CRL Disribution Point (CDP)
  The CDP field is a pointer to HTTP or LDAP distribution points for certificate revocation lists (CRL).  The CRL is a means of ensuring the certificate's current validity and can cause certificates to be incorrectly identified as revoked if the path is unreachable.
• Private Key Usage Period
  The maximum period of time that the private key is allowed to be used (deprecated)
• Certificate Policies
  Entries in this section provide links to the certification authoritiy's Certification Practice Statement (CPS) as well as the user notice.  The CPS is a legal document governing the practices associated with certificate handling for an organization.
• Policy Mappings
  This field is used to map certificate policies between the issuing CA and the certified entity by policy ID.
• Supported Algorithms
  A list of algorithms supported by the certified entity
• Subject Alternative Name
  The subject alternative name (SAN) field can contain one or more alternate identities for the certified entity.  These entries can be any instance of GeneralName.  Valid types for GeneralName are:
• Other Name
  Yet another reference to extend the naming capability, use of this allows specification of anything available in the OTHER-NAME information object class
• RFC 822 Name
  Another name for rfc822Name is the subject's e-mail address
• DNS Name
  A DNS name meeting specifications outlined in RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt)
• X.400 Address
  The X.400 standard governs message handling and look similar to the X.500 directory services standard, however addressing elements such as the country name, organization name, given name, surname, initials, etc.)
• Directory Name
  This is the distinguished name of the subject
• Electronic Data Identifier (EDI) Party Name
  The ediPartyName attribute allows the certificate to specify an alternative authority (referred to as a nameAssigner) that has assigned a name to the subject.  An example of where this might be of use is in federation whereby another directory service is asserting the name of a certified entity.
• Uniform Resource Identifier (URI)
  This field contains a uniform resource identifier, or URI, conforming to RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt).  URIs usually look similar to a uniform resource locator (URL), however they are used to provide a hierarchical association of an attribute.  URIs are commonly used in XML to uniquely identify a schema and are commonly confused with URLs due to their similarity, however a URI does not need to be a reachable networked location.
• IP Address
  IP address of the certified entity
• Registered ID
  An object identifier (OID) that can be used to identify the certified entity
• Issuer Alternative Name
  As with the subject alternative name, the issuer alternative name provides other valid names which may be used to identify a certificate's issuer.  All names provided by the GeneralNames type (the same one used in the previous Subject Alternative Name field) are valid for this field.
• Subject Directory Attributes
  The subject directory attributes field contains attributes of the certified entity (for example, perhaps a user's nationality) and cannot (per standard) be marked as a critical extension.  A good example of how this might be used would be when you want to assert a non-identifying attribute about the certified entity.
• Certification Path Constraints: Basic Constraints
  This field is used to determine whether the current certificate is a certification authority as well as an integer value limiting the maximum depth allowed in the CA chain.  Put simply, this field can prevent certificates not intended to be used as a CA from acting as one (doing so would add to the path length and violate the certificate's constraint)
• Certification Path Constraints: Name Constraints
  The name constraints field can be used to limit what name spaces the CA is authoritative for.  For example, it could enforce that a CA is only valid for names ending in .microsoft.com thus preventing issued certificates from being valid for .live.com addresses, etc.
• Certification Path Constraints: Policy Constraints
  The policy constraints field can be used to either enforce or prohibit the definition of a CA policy in issued certificates.

The Object Identifier (OID)

Data in X.509 certificate is organized by object identifiers, or OIDs.  OIDs are a hierarchical dotted integer notation used to describe the different types of data stored in a certificate and their associated formatting and have enabled the success of X.509 certificates due to their extensibility (organizations or software wishing to add custom attributes to a certificate are able to by establishing their own unique identifier structure).  As this topic is primarily formatting-related and quite lengthy I will refer anyone interested in digging into this to the Open Group's specification located here: http://pubs.opengroup.org/onlinepubs/009609799/index.htm.

Common File Formats for X.509 Certificates

Certificate files are written using Abstract Syntax Notation (ASN.1) and require a converter to become human-readable.  The most common encoding of individual certificates are DER encoded binary x.509 or Base-64 encoded X.509, or Public Key Cryptography Standard (PKCS) #7 formats (see RFC 2315 http://tools.ietf.org/html/rfc2315 and RFC 5652 http://tools.ietf.org/html/rfc5652).  PKCS #7 also enables the storage of multiple certificates in a single file and can be useful to establish trusts with non-public certification authorities where the AIA path may not be accessible (this topic will be covered later). 

PKI is based on an advanced mathematic relationship called asymmetric cryptography discovered by two Stanford mathematicians, Whitfield Diffie and Martin Hellman, in 1976 (ref: http://purl.umn.edu/107353).  These mathematicians were faced with two major problems in cryptography: key distribution and identification.  In response to these issues, Diffie and Hellman identified a relationship between large prime numbers whereby data encrypted with one key could only be decrypted by its paired key.  Due to the difficulty involved in establishing the relationship between these large prime numbers, it is unfeasible to reverse-engineer the relationship with a key of any significant size.  This mathematic relationship was eventually called the Diffie-Hellman  key exchange (ref: http://cr.yp.to/bib/1988/diffie.pdf, patent: http://www.docstoc.com/docs/31206972/Public-Key-Cryptographic-Apparatus-And-Method---Patent-4218582).

Interestingly enough, another set of mathematicians by the names of Ron Rivest, Adi Shamir, and Leonard Adleman identified the same relationship in 1978 and published it as the RSA (based on their initials) algorithm (ref: http://people.csail.mit.edu/rivest/Rsapaper.pdf, patent: http://www.patents.com/us-4405829.html).  Though Diffie and Hellman discovered the concept of asymmetric cryptosystems first, RSA monetized the concept more effectively ultimately resulting in RSA Corporation, now owned by EMC.

PKI as we know it began with establishment of the X.509 certificate standard in 1993 with the establishment of RFC 1422 (ref: http://tools.ietf.org/html/rfc1422).  This standard created the concepts of certification authorities, certificate revocation lists (CRL), and certificate trusts that provided the framework for more advanced PKI-based technologies in-use today.

In asymmetric cryptography two mathematically related keys are generated; the public key and the private key. The relationship of these keys is such that any data encrypted by one key can only be decrypted by its matched pair. To clarify this relationship, the public key cannot decrypt data encrypted by the public key and the private key cannot decrypt data encrypted by the private key.

In this relationship, the private key identifies the identity of the certified asset, while the public key is widely distributed to validate its identity. An important thing to note at this point is that the compromise of the private key must immediately result in invalidation of this relationship (the means to accomplish this will be discussed later).

The relationship between these keys enables two important cryptographic capabilities based on use: confidentiality and integrity.

PKI can be used to ensure the confidentiality of data transmission through use of the recipient's public key. Two common examples of this are in secure sockets layer (SSL) encryption and e-mail encryption

In SSL encryption, a Web server is configured to use a PKI certificate to establish a trust and cryptographic relationship between clients and the server. In this design, the SSL client requests the server's certificate (containing its pubic key) for encryption of a symmetric key that will be shared by both parties for further communications. Because the client has the server's public key it can be reasonably assured that only servers having the private key will be able to decrypt the symmetric key and therefore ensuring confidentiality. There is much more to this topic than discussed in this section, some of which will be discussed later in a later post.

Similar to SSL encryption, e-mail encryption leverages the recipient's public key (available in their certificate) to ensure that only recipients of the e-mail will be able to read the message. In this form of encryption, the e-mail message is encrypted using symmetric encryption. The resulting key is then encrypted separately with each recipient's public key to ensure only the intended recipients of the message are able to view its contents (due to their possession of their corresponding private key).  This concept will be discussed in-depth in a later post.

Another common use of PKI is to ensure the integrity, authenticity, or to prevent repudiation (refusal to acknowledge an action). In these operations, the private key to guarantee the sender through cryptography. It is important to make the distinction that cryptographic operations performed by the private key usually do not provide confidentiality (rather obfuscation at best) due to the intended wide distribution of the public key. Once common example of this is the use of digital signatures.

You may have received a digitally signed e-mail (identified in Outlook by a red ribbon) or have seen a warning message that a driver or piece of software was not digitally signed. Both of these scenarios leverage the relationship between the public and private key to certify that the digitally signed information (the e-mail, software, or driver) was produced by a trusted source and has not changed since the digital signature.

Digital signatures begin by taking the data to be signed (either the e-mail contents or the compiled code in the above examples) and passing it through a hashing algorithm. Hashing algorithms are special formulas that produce a unique fixed-length output when given a specific input (for more information on this research HMAC or CBCMAC formulas). In addition, effective hashing algorithms will change the entire result if any part of the source message changes. Also, the resulting hash should not be able to be reverse engineered to provide the original message.

The hash alone only proves that the message has not changed. To prove the identity of the sender this hash is then encrypted using the sender's private key resulting in a digital signature. This digital signature can then be used to verify the identity of the sender (the ability to decrypt the signature) as well as to validate the integrity of the message through performing the same hashing algorithm and comparing.  As with the previous topics, this will be discussed in-depth in an upcoming post. 

Many applications today use Remote Procedure Calls to link client and server communications over a network.  RPC allows client applications to easily perform function calls to local and network-connected server applications using native Windows APIs.  Among the benefits of using RPC are:

• Flexible communications as defined by an Interface Definition Language (IDL) file supporting a wide range of protocols to include TCP, UDP, and NetBIOS
• Ability to automate network port selection to avoid conflicts
• Offloading of authentication, packet integrity (digital signatures), and strong encryption
• Ability for clients to locate remotely published server services locations through use of the RPC Endpoint Mapper

Because of these benefits (as well as many others) RPC is an attractive communications platform for software development and is used widely in client-server communications. 

Firewalls and RPC

RPC provides a large number of security benefits as discussed above, however it does have an associated cost.  Many applications that use RPC leverage a feature called dynamic port allocation.  When an application uses dynamic port allocation it offloads the network port number selection to the RPC server service that it is being hosted on.  The result of this is that each server will use a different TCP port to host the same service.  As a result, white papers specifying ports that must be opened to allow these servers to communicate across firewalls include a range of thousands of (commonly TCP) ports which must be opened.  In addition, using implicit bindings means exposing any other RPC-hosted services in an accessible manner to services hosted in a different and possibly lower security zone.  In the case of domain membership, this runs the risk of exposing the very core of a network’s authentication mechanism (Active Directory) to the risk of compromise due to vulnerability in a service hosted on a domain controller whose communication may not even be necessary for domain membership.

How does RPC work?

When a service uses RPC on Windows it registers with the RPC Endpoint Mapper service using one of a number of functions.  There are a large number of ways that an application can register an endpoint on the endpoint mapper, many of which are listed at http://msdn.microsoft.com/en-us/library/aa375262(v=vs.80).aspx.  The most important aspect of this registration when discussing load balancing is the difference between explicitly specifying the TCP port that the application uses versus allowing the application to leverage the RPC server’s dynamic port allocation capability.

Dynamic Port Allocation

Applications leveraging dynamic port allocation will use a function such as RpcServerUseProtseq(), RpcServerUseAllProtSeqs(), RpcServerUseAllProtseqsEx(), or RpcServerUseProtseqEx() to enable the RPC server to dynamically choose a TCP port to host the service on (ref: http://msdn.microsoft.com/en-us/library/aa378682(v=vs.80).aspx).  When an application uses a function like this the RPC server will dynamically pick a port from a range between 1024 and 65535 by default (this behavior can be modified as outlined in the following Microsoft KB http://support.microsoft.com/kb/250367 or through changing the TCP dynamic ports as outlined in the following KB http://support.microsoft.com/default.aspx?scid=kb;EN-US;929851).

Explicit Port Allocation

If the software developer wants to explicitly specify the TCP port that they want to use they have the option of using a function such as RpcServerUseProtSeqEp() or RpcServerUseProtseqEx() to specify a specific TCP port to use for the application.  After getting an endpoint from one of the above functions, the application will usually then call RpcEpRegister() to register the new port with the Endpoint Mapper.  In many Microsoft applications (such as Active Directory and Exchange) this option is used only if a given registry key is configured (references – Active Directory: http://support.microsoft.com/kb/224196, Exchange 2010: http://social.technet.microsoft.com/wiki/contents/articles/configure-static-rpc-ports-on-an-exchange-2010-client-access-server.aspx).  In this event, the software will try to use the given TCP port rather than leveraging the dynamic port allocation abilities of the RPC server.

How Clients Locate a RPC Service

The next logical question that comes to mind is “If the TCP port is randomly assigned, how does a client on the network find out which port to connect to?”  Associating these ephemeral ports to the hosted server application is a function of the RPC Endpoint Mapper.  The RPC Endpoint Mapper is essentially a phone book containing a list of mapped ports and their associated UUID (a unique ID specified by the application mapping the connection).  Applications wanting to connect to a service indexed by the endpoint mapper will first connect to the hosting server on TCP port 135 using a function such as RpcStringBindingCompose() to search the server’s endpoint mapper for the serivce's UUID (ref: http://msdn.microsoft.com/en-us/library/windows/desktop/aa378481(v=vs.85).aspx).  The UUID is an identity specified by the application developer during the development of the application and is commonly done through use of an Interface Definition Language (IDL) file (ref: http://pubs.opengroup.org/onlinepubs/9629399/chap4.htm).  For an example of an IDL file perform a search for *.idl in your %ProgramFiles% directory.  Once a client finds the location of the service it closes the connection to TCP 135 and initiates a new connection to the server on the referenced TCP endpoint.

How Load Balancers can cause Issues with RPC Traffic

When an application uses a load balancer, multiple instances of the server are housed under the same DNS name or IP address.  The problem is that in a load balanced scenario without persistence the back-end server that the client is communicating with can change without notice.  Once bound, the client software commonly makes the assumption that these services will remain available throughout its session with the load balanced server and may make subsequent calls directly to the ephemeral port hosting the service without contacting the RPC Endpoint Mapper.  If port allocation for this service is dynamic it is highly unlikely that multiple servers performing the same role will use the same TCP port for the same RPC service.  As such, a load balancer that cannot maintain session persistence is subject to connection failures anytime the load balancer switches the client’s back-end server.

For this example we will use a network consisting of two servers (“Server A” and “Server B”) that each host a service (“Service X”)  and are load balanced by a network load balancing device (“loadbalancer.mycompany.com”).

Test Network Diagram

The client connects to “loadbalancer.mycompany.com” and gets “Server A” on the other side of the load balancer.  Due to RPC dynamic port assignment, “Server A” hosts “Service X” on TCP port 11111, while “Server B” hosts “Service X” on TCP port 22222.  The client has an application installed that uses “Service X” over RPC and is configured to connect to it using “loadbalancer.mycompany.com”.

 At this time, the client uses RpcEpResolveBinding() to find the location of “Service X” for “loadbalancer.mycompany.com”.  The load balancer forwards the connection to “Server A” which responds that it hosts “Service X” on TCP port 11111.  At this time, the client calls RpcStringBindingCompose() to connect the software to “Service X” on TCP port 1111 at “loadbalancer.mycompany.com”, and finally RpcBindingFromStringBinding() to obtain a handle to this resource.  When the client makes this call to the load balancer the load balancer fails to persist the client to “Server A” and instead forwards the connection to “Server B”.  Since “Server B” does not have this port open it responds to the TCP SYN packet with a TCP RST-ACK (ref: http://support.microsoft.com/kb/175523).  The client will continue this until it reaches TCP_MAX_RETRANSMISSIONS (ref: http://support.microsoft.com/kb/170359) at which time it determine the network connection to be failed.  When the client calls RpcBindingFromStringBinding() it is returned the following error: RPC_S_INVALID_NET_ADDR (ref: http://msdn.microsoft.com/en-us/library/windows/desktop/aa378645(v=vs.85).aspx).  At this time, the client must make the assumption that the service is unavailable and will invoke its error handling functions as designed.

In this configuration, this condition can happen due to multiple causes (ex. “loadbalancer.mycompany.com” fails to persist the connection to the originating server, the service on “Server A” stops or restarts causing the load balancer to move the connection, etc.).  In any of these situations the client will repeat the above scenario thus resulting in connection issues.

How to Prevent this RPC Connection Issue

To effectively mitigate these issues all servers hosting one of two things must occur:

• The RPC service must be configured to use the same explicit RPC port(s) across all servers providing the service under the load balanced name or
• The RPC client must be developed to contact the RPC endpoint mapper in the event that it receives a RPC_S_INVALID_NET_ADDR error and the network load balancing device must be able to reasonably persist connections to the same server (we have to ensure that the TCP endpoint mapper call and the immediate following call to the RPC-hosted service are successful).  Also, in the event that this persistence is not maintainable over a length of time this solution will be unnecessarily chatty.

Since most systems administrators do not have source code access to the software they are maintaining the RPC server service must be configured to utilize the same TCP port across all server services hosted under the load balanced DNS name.  For example, if the server service hosted by the cluster is Exchange then all Exchange servers must be configured to use the same ports for Exchange services across all nodes in a cluster.  In addition, the clustered application must be able to handle session transitions between servers to accommodate for a failover condition (i.e. in the event that the session is sent from one server to the other it must be able to recover or restart the session without reinitialization).