“PKI Proposal” : why do you need an internal PKI ?

One of the things that any IT pro should understand and spend time doing, is to secure his infrastructure and applications. Nowadays, everything you do in your infrastructure or any new Microsoft solution, depends heavily in digital certificates to authenticate, sign or encrypt things.

I guess investing in an internal PKI infrastructure is a must in all corporations and networks. If you want to have SSL, TLS , Bitlocker DRA, IPsec, PEAP, EAP-TLS , 802.1x authentication, code signing, driver signing, EFS, or even S/MIME, you will have to use some sort of digital certificates.

Moreover, every Microsoft product being released, requires and depends on digital certificates. Take Exchange or Lync for example.

Not only this, if you want to integrate with third party solutions, you would need some kind of certificate to authenticate the transaction. I came over a Polycom device that needs a certificate to talk to Lync servers. This makes sense, because you need a way to establish a trust channel before forwarding your traffic between two different devices or applications.

I have written a small PKI proposal explaining why a corporate needs to consider an internal PKI solution, and what is the cost for not having one.

You can find the document here :http://sdrv.ms/InAJvc

PKI – Certificate Authority CA Backup

One of the important things you need to do is to backup your certificate authority servers. In this post, i will give you some of my best practices about how to backup a CA that i came up from my experience.

1. System State Backup (Full backup ,not differential)

This is the preferred method of backup up a CA. It includes the following components related to CA services:

  • CA database: includes information about any certificate issued or revoked.
  • CA key Pair: The backup should include all versions of the CA certificates in case of CA certificate renewal.
  • IIS metabase: important if changes are made to the Certificate services web enrollment pages.
  • Registry settings: CA settings.

2. Manual Backup

Can backup only (CA Database) and (CA Key pair). Performing backup to the registry or IIS metabase is required additionally.

Manual backup can be performed via the GUI Console or by using the (certutil) :

  • Manual backup using CA console :

1. From the Start menu, point to Administrative Tools and click Certification Authority. In the console tree, ensure that Certificate Services is running.

3. In the console tree, right-click CA Name, point to All Tasks and click Backup CA.

4. On the Welcome to the Certification Authority Backup Wizard page, click Next.

5. On the Items to Backup page, input the following options:

      • Private Key and CA certificate. Includes the CA’s certificate and private key(s) in the backup set. Select this option only if you are using software CSP. If using hardware CSP, leave this check box cleared.
      •  Certificate database and certificate database log. Always select this option to ensure that you include the CA database and log files in the backup set.
      •  Perform incremental backup. This check box is not usually selected. Full backups of the CA database and log files are recommended instead.
      •  Backup to this location. Select a folder on the local file system that does not contain any existing data.

6. If the Certification Authority Backup Wizard dialog box appears, click OK to create the location designated on the Items to Backup page.

7. If you choose to back up the private key and CA certificate, open the Select a Password page, type and confirm a password to protect the PKCS #12 file generated by the backup procedure, and click Next.

8. On the Completing the Certification Authority Backup Wizard page, click Finish.

Once the backup is complete, open the folder designated in step 5. In the folder, there is a *.p12 file (the PKCS #12 backup of the CA’s certificate and private key) and a sub folder named Database that contains the backup of the CA database and log files.

  • Manual backup using certutil :

If you are using a software CSP, ensure that the backup set includes both the CA database and the CA’s key pair. To do this, use the following procedure:

1. Open a command prompt.

2. At the command prompt, type net start certsvc to ensure that Certificate Services is running.

3. Create a folder that will contain the results of the manual backup of the CA database—for example, C:\CABackup.

4. At the command prompt, type certutil –backup C:\CABackup and press ENTER.

5. At the command prompt, at the Enter New Password prompt, type a complex password and press ENTER.

6. At the command prompt, at the Confirm New Password Prompt, type the same password again and press ENTER.

7. When the backup is complete, ensure there are no error messages and close the command prompt.

You are providing a password to protect the PKCS #12 file containing the CA’s key pair. To create a successful backup of the private key, you must be a local administrator of the computer; to create the backup of the CA database, you can only hold the Common Criteria role of backup operator. In other words, you can only run this command successfully if Common Criteria role separation is not enforced.

If Common Criteria role separation is enforced, you can separate the two backups by running two certutil commands.

To backup only the CA database, a backup operator can use the –backupdb option, as shown here:

1. Open a command prompt.

2. At the command prompt, type net start certsvc to ensure that Certificate Services is running.

3. Create a folder that will contain the results of the manual backup of the CA database—for example, C:\CABackup.

4. At the command prompt, type certutil –backupdb C:\CABackup and press ENTER.

5. When the backup is complete, ensure there are no error messages and close the command prompt.

Likewise, if you are a local administrator and only want to backup the CA’s key pair, you can use the –backupkey option to backup the CA’s private key and public key to a PKCS #12 file.

1. Open a command prompt.

2. At the command prompt, type net start certsvc to ensure that Certificate Services is running.

3. Create a folder that will contain the results of the manual backup of the CA database—for example, C:\CABackup.

4. At the command prompt, type certutil –backupkey C:\CABackup and press ENTER.

5. At the command prompt, at the Enter New Password prompt, type a complex password and press ENTER.

6. At the command prompt, at the Confirm New Password prompt, type the same password and press ENTER.

7. When the backup is complete, ensure there are no error messages and close the command prompt.

Note Ensure that you have included the registry in the backup by including the SystemState in the backup set or by manually backing up the HKLM\System\CurrentControlSet\Services\CertSVc\Configuration\CAName registry key.

So what is my recommendation ? Well, i recommend to take system state backups in daily basis of the CA server, and to schedule a batch file to take backup of the database using the certutil -backupdb to a folder, and then to include this folder on your normal backup cycle. I also recommend if you can export the private key of the CA and keep it safe. Don’t forget to backup  HKLM\System\CurrentControlSet\Services\CertSVc\Configuration\CAName registry key. It contains all your CA configuration

A,B,C Cryptography (Picture Story)

Cryptography came from Spartans Military (Greeks)

CryptoGraphy

Kryptos means Hidden

Gráphō means writting

Crypto12121

Transposition Method

5th century BC – Spartan generals exchanged secret messages by wrapping narrow ribbons of parchment around a cylindrical staff known as a scytale, then transcribing their messages on the papyrus. The messages could only be read when the papyrus was re-wound around a scytale of the same thickness.
Crypto23232

The diameter of the cylinder , therefore is the key

Crypto3433

Substitution Method

The scytale method was used by the government officials of Sprta to communicate with their military officer.

It was not until a couple of centuries later that another popular encryption method arises: The ceasar cipher, named after Julius Caesar.

Crypto343343

CODE BOOK

Crypto33322

Each Letter is replaced by only one cipher symbol

MONO-ALPHABETIC

Cryptosdsd

Cryptanalysis Era

Crypto443

Crypto434

The problem so far for Cryptography

There is no distinguish between cryptographic system and key because system were so simple (code book is the key, and the system is mapping plain text to cipher)
All the expense is making the code book and making the secret piece.

Polyalphabetic

All the expense is on the public piece

Symmetric Encryption

Cryptoaass

Diffie Hellman

Cryptossa

RSA Asymmetric Encryption

(Public key and Private Key)

Crypto33232

THE END

Copy rights : All screenshots are taken from my own presentation that i did upon graduation.

PKI Certificate Services Privacy Statement

 

Hi, usually if you are a big organization and you have an internal PKI implementation, you would usually need some kind of privacy statement in place. The audience of this statement are any person who will interact with your PKI infrastructure directly or indirectly. For example, people who are holding certificates from your PKI infrastructure should be aware of this privacy statement.

I have read all best practices and RFCs that are talking about this topic and i came with a sample PKI Privacy Statement that you can download and use it at your side.

In some companies, i see that they have a portal with links to their PKI privacy statement, their certificate policy and other publicly accessible PKI policies.

Download the Sample PKI Privacy Statement here

Contoso Certification Services Privacy Statement

Forefront Identity Management FIM CM Permission Model Examples

Sometimes it is very tricky to assign permission on your FIM CM model. Here is couple of practical examples :

Example 1 – Self Service Registration Model

 Requirements:

  • The certificate subscriber initiates the request for the smart card.
  • The request is left pending until a certificate manager approval.
  • One approved, the certificate subscriber execute the smart card request.

Permissions:

  • SCP and Subscriber Group: Assign the approval manager both Read and CLM Audit.
  • Profile Template: Assign the subscriber Read and CLM Enroll on the profile template.
  • Certificate Template: Assign the subscriber Read and Enroll on the profile template.
  • Management Policy: Ensure that Self Service is enabled on the General Settings, and assign the manager: Approve requests.

Note: Although the user is going to initiate and execute the enrollment, you don’t need to give him any FIM Extended Permissions. Instead, enabling the Self Service in the management policy is sufficient.

Example 2 – Manager Initiated Registration Model

 Requirements:

  • The certificate manager initiates the request.
  • If further approvals are required, then another manager should approve it.
  • One approved, OTP is sent to the subscriber.
  • The subscriber inputs the OTP and completes the request.

Permissions:

  • SCP and Subscriber Group: Assign the approval manager both Read and CLM Request Enroll.
  • Profile Template: Assign the subscriber Read and CLM Enroll on the profile template. Assign the manager Read permission.
  • Certificate Template: Assign the subscriber Read and Enroll on the profile template.
  • Management Policy: Assign the first manager initiate privilege .Assign the manager: Approve requests.

Example 3 – Centralized Management

Requirements:

  • There are four parties here :
    • FIM Full admins: Has Full Permissions.
    • FIM Security Officer: Enroll smart card for users.
    • FIM Help Desk: Unblock Smart Cards.
    • FIM Subscribers.
  • FIM Security Officer Initiates the smart card request and executes the enrollment for smart cards (Smart Card PIN is randomized).
  • FIM Subscribers receive their smart card, log to the FIM portal to perform the initial online unblock.
  • FIM Help Desk will perform offline unblock operations if needed.

Permissions:

  • SCP and Subscriber Group:
    • FIM Full Admin: Full Permissions.
    • FIM Security Officer: Read and all FIM Extended Permissions.
    • FIM Help Desk:  Read + CLM Request Offline Unblock + CLM Enrollment Agent.
  • Profile Template: all four parties will have Read and CLM Enroll.
  • Certificate Template: FIM Full Admin and FIM Security Officer will have Read and Enroll.
  • Management Policy:
    • Enroll Policy: “Initiate Enroll Request” and “Enroll Agent For Enroll Requests”: FIM Full Admins and FIM Security Officer.
    • General Settings: Self Service Disabled.
    • Offline Unblock policy: “Initiate Offline Unblock Requests” and “Unblock Agent for Offline Unblock Requests”: FIM Full Admin, FIM Security Officer and FIM Help Desk. 

 

 

Forefront Identity Management FIM CM / Smart Card Management (Level 400)

If you are a FIM CM Administrator, then part of your work is to manage smart cards using the FIM CM Portal.

It is so difficult to understand what will happen to the certificates in smart cards when performing smart card management tasks. This blog post will present a nice diagrams to show you what will happen in a nice way according to my own tests 🙂

The diagrams will use E to indicate an encryption certificate and S to indicate signing certificate.

  • PERM : mean permanent smart card
  • DUB : means duplicate smart card
  • REP: means replaced smart card
  • Red line across the certificate :means revoked certificate

Smart Card Replacement

Assumptions : FIM portal is configured with the following settings :

  • Workflow: Duplicate Revocation Settings : Not configured
  • Workflow: Revocation Settings:
    • Set old card or profile status to disabled
    • Revoke old certificates.
  • Workflow: General:
    • Re-issue archived Certificates.

Now, this is what will happen : If you have a smart card with E1 and S1 (Encryption and signing certificates inside the smart card) , and you happen to have a duplicate smart card (DUB) with of course E1 and S2 (the same encryption certificate but different signing certificate), then replacing the permanent smart card will do what the figure shows.

  • Upon replacing your permanent smart card, the encryption certificate E1 will be revoked on the permanent and duplicate smart card and the signing certificate on the permanent smart card will be revoked (S1) while the signing certificate on the duplicate smart card will not be touched.The final replacement card will contain a new signing certificate (S3) and a new encryption certificate (E2) and a copy of the old E1 encryption certificate to be used to decrypt any content that was encrypted using E1. New encryption though will be using the new E2. Note that you can always decrypt using a revoked certificate. The permanent card will be set to Disabled state if you configured the workflow revocation settings in FIM portal to (Set old card or profile status to disabled)
  • If you replace the duplicate smart card though, the opposite will happen.
  • If you now duplicate the replacement smart cared, a new signing certificate will be issued (S4) and the remaining is the same.

Note : Since signing certificates are not archived at the CA (this is what you should configure the CA to do), then you will always have a new signing certificate no matter what the operation you are doing to the smart card is.

SC_Management_dfgdfg33

Smart Card Retirement 

Scenario 1 : Retire a duplicate smart card 

1.     Revoke all certificates on the Duplicate Card – Duplicate smart card will not be anymore assigned to the user – smart card doesn’t have any certificates as they are deleted.

2.     Disable the permanent Smart Card (which will revoke all certificates on the card) –Permanent smart card will still assigned to the user –smart card still have certificates but are revoked so they can be used to recover encrypted files.

Scenario 1 : Retire a permanent card that has a duplicate smart card

1.     Revoke all certificates on the Permanent Card – Permanent Card will not be anymore assigned to the user – smart card doesn’t have any certificates as they are deleted.

1.     Disable the Duplicate Smart Card (which will revoke all certificates on the card) –Duplicate smart card will still assigned to the user –smart card still have certificates but are revoked so they can be used to recover encrypted files.

 

SC_Management_3333334443

Disable Smart Card

SC_Management_3232323

Duplicate Smart Card

FIM will recover the same Encryption certificates (if archived) and will always issue new signing certificates.

SC_Management_33234423

Online Update a Smart Card – Case 1

Assumptions:

User X is enrolled for two smart cards , in which one of them is Duplicate .The Online Update Policy is configured to (Revoke Archived Certificates) both in the (Certificate Content Change) and (Certificate Expiry) reasons. Smart cards are enrolled using a profile templates that contains two certificate templates (Encryption Certificate Template and Signing Certificate Template)

Action: Administrator performed online update for the PERM card and chooses (Certificate Content Change) and chooses to update only (Signing Certificate Template).

What will happen:

Online Update cannot be done fully from the administrator workstation. Thus , the (Update Initiator) will initiate the request of Online Update for a smart card , after this action is approved in a workflow as described in the management policy workflow ,the user will should logon to the FIM Client site and should check his requests. He will see two approved Requests for Online Update (one for each card).The user then should insert his permanent smart card and choose to execute the first approved online update ,and then insert the second duplicate smart card and choose to execute the second approved online update.

The user will end up with two smart card with the encryption certificate non touched .But both signing certificates on the smart cards will be revoked and deleted and new ones issued and printed on the smart cards as shown on the figure below.

SC_Management_aaaaa

 

Online Update a Smart Card – Case 2

Assumptions:
User X is enrolled for two smart cards , in which one of them is Duplicate .The Online Update Policy is configured to (Revoke Archived Certificates) both in the (Certificate Content Change) and (Certificate Expiry) reasons. Smart cards are enrolled using a profile templates that contains two certificate templates (Encryption Certificate Template and Signing Certificate Template)

Action: Administrator performed online update for the PERM card and chooses (Certificate Content Change) and chooses to update only (Encryption Certificate Template).

What will happen:

Online Update cannot be done fully from the administrator workstation. Thus, the (Update Initiator) will initiate the request of Online Update for a smart card, after this action is approved in a workflow as described in the management policy workflow, the user will should logon to the FIM Client site and should check his requests. He will see two approved Requests for Online Update (one for each card).The user then should insert his permanent smart card and choose to execute the first approved online update ,and then insert the second duplicate smart card and choose to execute the second approved online update.

The user will end up with two smart card with the signing certificates non touched .But the encryption certificate (E1) will be revoked and kept on the smart cards for recovery usage. Now, a new encryption certificates E2,E3 will be issued and printed on the cards as shown on the figure below.

The user will end up with two cards and with two encryption certificates E1 and E2 .To solve this ,you can now retire Smart card DUB (this will revoke and delete S2,E2) and then duplicate the PERM card .After all is done ,the DUB card will have ( S3,E2, and the revoked E1).

 

SC_Management_fgd54dgdrgd

 

Online Update a Smart Card – Case 3

Assumptions:
User X is enrolled for two smart cards , in which one of them is Duplicate .The Online Update Policy is configured to (Revoke Archived Certificates) both in the (Certificate Content Change) and (Certificate Expiry) reasons. Smart cards are enrolled using a profile templates that contains two certificate templates (Encryption Certificate Template and Signing Certificate Template)

Action: Now the administrator deleted the signing certificate from the profile template and initiated an online update of the smart card (doesn’t matter if it is the PERM card or the DUB card).

What will happen:

Online Update cannot be done fully from the administrator workstation. Thus, the (Update Initiator) will initiate the request of Online Update for a smart card, after this action is approved in a workflow as described in the management policy workflow, the user will should login to the FIM Client site and should check his requests. He will see two approved Requests for Online Update (one for each card).The user then should insert his permanent smart card and choose to execute the first approved online update ,and then insert the second duplicate smart card and choose to execute the second approved online update.

The user will end up with two smart card with the signing certificates revoked and deleted .The encryption certificate is not touched.

SC_Management_sdsfsf

 

Online Update a Smart Card – Case 4

Assumptions:
User X is enrolled for two smart cards , in which one of them is Duplicate .The Online Update Policy is configured to (Revoke Archived Certificates) both in the (Certificate Content Change) and (Certificate Expiry) reasons. Smart cards are enrolled using a profile templates that contains two certificate templates (Encryption Certificate Template and Signing Certificate Template)

Action: Now the administrator deleted the Encryption certificate from the profile template and initiated an online update of the smart card (doesn’t matter if it is the PERM card or the DUB card).
What will happen:

Online Update cannot be done fully from the administrator workstation. Thus, the (Update Initiator) will initiate the request of Online Update for a smart card, after this action is approved in a workflow as described in the management policy workflow, the user will should logon to the FIM Client site and should check his requests. He will see two approved Requests for Online Update (one for each card).The user then should insert his permanent smart card and choose to execute the first approved online update ,and then insert the second duplicate smart card and choose to execute the second approved online update.

The user will end up with two smart card with the Encryption certificates revoked and deleted .The signing certificates is not touched.

SC_Management_asdaa3

 

 

WOW.. That was a lot of info and testing ! hope you find it nice post 

PKI – Certificate Web Enrollment Services

Introduction

Certificate enrollment before windows server 2008 R2 was performed using one of the following methods:

  1. Using the Web Enrollment Pages
  2. Requesting certificate by utilizing the certificate authority DCOM calls (RPC).
  3. Third party tool that will proxy enrollment requests like FIM CM 2010. 

It is obvious that every method mentioned above has its own limitation:

  1. Web Enrollment Pages, simply would replace the client. The client will initiate HTTP request to the web enrollment pages and the enrollment pages will query ADD for all lists of templates and converting the client’s HTTP request into DCOM request that can be sent to the CA. So the client doesn’t have direct access to the CA. This way of enrollment is completely manual process and doesn’t support auto enrollment.
  2. Requesting certificates using DCOM to the CA. In his method, clients need LDAP access to a domain controller to determine the certificate templates available and which CA servers are publishing them.

Actually the client will perform the following LDAP queries to the AD:

      • Queries for a list of pKICertificateTemplate objects (Certificate Templates) within the forest.
      • Queries for a list of pKIEnrollmentService objects (Enterprise CA’s) within the forest.
      • Queries for a list of msPKI-Enterprise-Oid objects within the forest.

Once all of objects are returned to the client, it determines what Enterprise CA’s are available, and what certificate templates can be issued by each one of them. The client then determines the certificate templates for which it has permissions to enroll or auto enroll.

Once the client selects the certificate template for which to enroll, a DCOM connection is made to the CA. DCOM connects to the CertSrv Request DCOM interface to enroll for the certificate. The certificate is then handed back to the client.

The limitation here is it is not practical to expose DCOM access to the CA server itself and this doesn’t work if you want to enroll external clients without connectivity to corporate network. On the other hand , this will not work for clients not joined to the corporate domain.

3. Third Party tool like FIM CM 2010 is great tool for issuing smart cards and user certificate. It doesn’t support issuing computer certificates or auto enrollment.

CA_WebEnrollment_23232

Certificate Web Enrollment Services

 

 Benefits

Windows Sever 2008 R2 came with many enhancements and it extend the methods clients can enroll for certificates by utilizing web services. The main advantages are:

  1. Non-domain joined workstations. They are unable to authenticate to a DC and perform the initial LDAP queries, and thus will never make it to step 2 – the RPC / DCOM call.
  2. Internet based clients that need to enroll for a certificate or renew a certificate.
  3. No need to expose DCOM interface for the certificate service. This is very important if there is a requirement that client computers should not be able to access the CA directly over the network, or there is a Firewall between the CA and client computer and your clients are Windows7 /2008R2.

Who does it work

The new services that support the new web enrollment services included in Windows Server 2008 R2 are:

  1. Certificate Enrollment Policy
  2. Certificate Enrollment Services

CA_WebEnrollment_44444

Step 1. Client connects to the CEP web service over HTTPS.

The Windows 7 / Windows Server 2008R2 computer is configured to enroll for certificates against a CEP server (specified via GPO or by specifying the CEP server manually via certificates snap in.

Step 2. CEP web service queries LDAP.

The CEP service will send an LDAP query to a domain controller to get the pKICertificateTemplate objects (Certificate Templates), pKIEnrollmentService objects (Enterprise CA’s) and msPKI-Enterprise-Oid objects within the forest.

Once all the objects are collected and sent back to the client computer it determines the types of certificate for which it can enroll and which enterprise CAs can issue those certificates.

There is a new attribute on the CA’s pKIEnrollmentService object that tells the client computer what the URI’s are for the CES servers in the environment. The attribute name is msPKI-Enrollment-Servers. The attribute is a multi-valued string so there can be multiple URI’s defined if you need to support different authentication methods.

Step 3. Client connects to the CES web service over HTTPS.

The client then connects to the CES web service that answers for the Certification Authority that is configured to issue the certificate. The actual CES URI is defined in the msPKI-Enrollment-Servers attribute on the pKIEnrollmentService object for that CA.

Step 4. CES web service impersonates the client security context to request a certificate via DCOM, and then hands the certificate back to the client.

Authentication Options

  • Integrated Authentication:  useful if clients who need to enroll certificates are joined to the domain and connected to the corporate network. It uses Kerberos and it the recommended method because it is the most secure and seamless method.
  • Client Certificate Authentication: this requires that machines are already provisioned with computer certificates before.
  • User name and password: this is used when enrolling to external clients or machines not member of the domain.

Load Balancing

Rather than relying on network load balancing (NLB) technologies, the policy and enrollment service client components have load balancing and fault tolerance logic built in.  For example, the clients will automatically randomize the list of endpoints they’re provided and attempt to iterate through the list if the first endpoint is unresponsive.  Thus, as long as multiple URIs are published, basic load balancing and fault tolerance is built in.

Internal deployment with integrated authentication

CA_WebEnrollment_2222

The following are some consideration to keep in mind when deploying CES and CEP internally and using Kerberos:

  1. It is recommended not to install CES and CEP on the CA server itself.
  2. If both CES and CEP are using Kerberos (Integrating authentication) , then they cannot be installed on the same server as simply there will be SPN collision ( both using same IIS application pool, and same protocol).That is why we recommend installing them on separate machines.
  3. You cannot install multiple CEP instances on the same machine
  4. It is possible to install multiple instances of the CES on the same machine if they use different authentication protocol (one instant uses integrated authentication while the other uses client certificates).
  5. It is recommended to run the application pool of the CES service using custom account.
  6. Since Kerberos is used on the CES server and it will enroll certificates on behalf of the user, then the following two steps must be done :
    1. Service principle name for the CES application pool account
    2. Account delegation ( those services “Kerberos only”) for the CES application pool account .Delegation should be made for the CA server for (HOST and RPCSS)
  7. CES application pool account should be :
    1. Member of the local IIS_USRS group
    2. Have Request Certificate permission on the CA server.
  8. The account that is used to install the services should be Enterprise Admin.

 

PKI – CRL Re-sign

In some scenarios, it may not be possible to publish a CRL from an offline CA. In this case, with Windows Server , the old CRL may be re-signed without using the certification authority. This process assumes the availability of the CA private key(s) outside of the CA to actually sign the CRL. To update an expiring CRL, the old CRL file will need to be retrieved first. It will be available in Active Directory if the CA is an EnterpriseCA or if Active Directory was accessible when the CA was installed, or in the %windir%\System32\CertSrv\CertEnroll directory on the CA machine itself.

The simple syntax for re-signing a CRL is

certutil -sign <existing CRL file name> <resigned CRL file name>

You can also add or remove serial numbers, or remove extensions, or change the length of time the CRL will be valid through the certutil.exe –sign command.

The default is to re-sign the CRL to be valid starting 10 minutes prior to the signature (to allow for clock skew), and a lifetime (NextUpdate) equal to the old CRL. Use the following command to publish the CRL to Active Directory. Certutil will state whether the object in Active Directory was updated or if it was already up-to-date.

certutil -dspublish <resigned CRL file name>

PKI – Certificate Services CA Backup RPO

My recommendation for CA backup strategy is :

  • For online CAs, full backups of the CA database should be taken beside a full back of system state.
  • For offline root CA , Full backup should be taken each time the offline CA is accesses (Publishing new CRL, renew CA certificate ,issue new certificates)

 

Note If you restore the previous night’s full backup, the CA is not aware of any certificates issued between recovery time and backup time if the log file directory is unavailable. The certificates issued in this time frame are valid.

The caveat is that you cannot revoke these certificates, as they do not appear in the Certification Authority console. Microsoft has implemented a custom exit module in Certificate Services to allow real-time, centralized logging of all CA transactions to a Microsoft SQL Server database. The information stored in this database allows certificates not included in the CA database due to restoration of the CA database to be identified, allowing the certificate to be revoked.

PKI – CA Server Replacement

Use the following process to move Certificate Services from one server to another server:

  1. Create a manual backup of the CA database, or gain access to the last manual backup of the CA database.
  2. Create or gain access to a backup of the CA key pair. If using a software CSP, you can include the key pair in the manual backup.
  3. In the Registry Editor, export the following registry key: HKLM\System\CurrentControlSet\Services\CertSVc\Configuration\CAName.
  4. Uninstall Certificate Services and remove the CA computer account from the domain.
  5. Turn off the existing computer, and remove the computer from the network.
  6. Do not reinstall or wipe the computer’s hard drive until the restoration to the new computer is verified.
  7. Build the replacement computer with the same disk partitioning as the original CA.Ensure that the new computer is assigned the same NetBIOS name as the computer being replaced.
  8. If the DNS entries are static entries, ensure that the IP address information for the new computer is the same as used on the computer being replaced. 
  9. If the computer is replacing an enterprise CA, join the new computer to the same domain as the computer being replaced.
  10. Ensure that you copy all configuration files for the replaced CA to the local disk of the replacement CA.
  11. Copy the original CAPolicy.inf file to the %windir% folder.
  12. Reinstall Certificate Services using the existing key pair saved in step 2 of this procedure.
  13. Restore the registry file saved in step 3 of this procedure.
  14. Restore the manual backup of the CA database.
  1. Verify that Certificate Services starts successfully.

PKI – CA Restore

The first step in restoring the CA computer is to ensure that Certificate Services is installed correctly and can be started and stopped. If you have a good backup of Certificate Services, whether the backup is a SystemState backup or a manual backup, you must first re-install Certificate Services using the same certificate and key pair.

To reinstall Certificate Services, ensure that the CA certificate and private key are available to the CA..For a software-based CSP, a local administrator of the computer can import a PKCS #12 into the local machine store. You can verify that the certificate is imported successfully by loading the Certificates MMC console focused on the local computer.

Once the CA certificate and private key are loaded or accessible to the CA, use the following procedure to install Certificate Services, using the previous CA certificate and private key:

  1. From the Start menu, click Control Panel and click Add or Remove Programs.
  2. In the Add or Remove Programs window, click Add/Remove Windows Components. In the Windows Components Wizard, in the Windows Components list, select the Certificate Services check box.
  3. In the Microsoft Certificate Services dialog box, click Yes.
  4. On the Windows Components page, click Next.
  5. On the CA Type page, select the previous role of the CA, enable the Use Custom Settings To Generate the Key Pair and CA Certificate check box, and click Next.
  6. On the Public and Private Key Pair page, set the following options:
    • CSP: The same CSP as used previously
    • Use an existing key: Enabled
    • Select the certificate with the same CA name as the subject
    • Use the certificate associated with this key: Enabled

Note The hash algorithm and key length will automatically populate based on the previous CA certificate.

  1. On the Public and Private Key Pair page, click Next.
  2. On the CA Identifying Information page, verify that the CA’s common name and distinguished name are correct and click Next.
  3. On the Certificate Database Settings page, verify that the database, database log, and, if used, shared folder paths are the same as the original CA. Enable the Preserve Existing Certificate Database check box and click Next.
  4. If the Microsoft Certificate Services dialog box appears, click Yes to temporarily stop IIS. If prompted, insert the Windows Server 2003, Enterprise Edition, CD in the CDROM drive or point to the media installation point on the network and choose the \i386 folder.
  5. On the Completing the Windows Components Wizard page, click Finish. Close the Add or Remove Programs dialog box.
  6. From Administrative Tools, open the Certification Authority console. Attempt to start Certificate Services.

If Certificate Services starts, you can proceed to restoring the last SystemState or manual backup.

Note: The above procedure keep talking about the fact that first thing to do is re-install certificate services  with the exact CA key pair and then perform system state restore or manual restore. The question is  how can I have the CA key pairs in the first place if the only thing I have is the system state backup files.

The answer of this question is the answer of another question: Can I have the private key and public key from a system backup only. Answer is yes. To do this ,go to a workgroup machine ,name it as the same as your CA ,but keep it disconnected from network to avoid name conflict. Restore system state on it, restart the machine and then look at the certificate store, you will find the CA key pair

PKI – CA Disaster Recovery Documentation

The following information should be documented:

  • CA Name
  • Computer Name
  • Distinguished name Suffix
  • CA Database path
  • CA Log files path
  • CAPolicy File
  • Key Length
  • CRL and AIA publication points
  • Cryptographic Service Provider CSP
  • Certificate Templates definition ( in worst case ,Active Directory should be rebuilt)
  • Permission and Users Rights Assignments
  • All specific settings in the properties of the CA in the Certification Authority consol
  • Any post installation script
  • Logical Disk Partitioning scheme for a CA computer : When restoring CA ,the disk volumes must implement the same drive letters. Disk volumes can be different in size or implement different RAID levels, but thee drive letters and location must remain the same for the A database ,log files and CA configuration folder (if implemented) and operating system

PKI – Key Recovery Agents KRA

Requesting the Key Recovery Agent Certificate

  • Create an active directory group (Security domain local) named (Key recovery agents CA Name )
  • Create a user account named KRA1_CA_Name and add the user to the previously created group.
  • Log on to the CA server with CA administrator account and add the certificates templates snap-in.
  • Adjust the Key recovery agent certificate template to allow the(Key recovery agents CA Name ) group both read and enroll permissions.
  • Log on to a windows machine with KRA1_CA_Name user account and type http://CAName/certsrv on an internet explorer. On the Welcome page, click the Request a Certificate link.
  • On the Advanced Certificate Request page, click the Create and Submit a Request to this CA link.
  • On the Advanced Certificate Request page, in the Certificate Template dropdown list, select Key Recovery Agent. On the Advanced Certificate Request page, in the Friendly Name box, type Key Recovery Agent, and click Submit.
  • On the Certificate Pending page, ensure that the Web page states that the request ID is in a pending state.
  • Close Internet Explorer.

Issuing the Key Recovery Agent Certificate

Once the certificate request is pending, the key recovery agent must have his or her identity validated by a certificate manager.

  • Log on to the issuing CA as a user assigned the Issue and Manage Certificates permission.
  • Open the Certification Authority console. Expand the certification authority name and click Pending Requests.
  •  Ensure that the Key Recovery Agent certificate requestor has met the defined certificate policy, right-click the pending certificate request in the details pane, point to All Tasks, and click Issue. Close the Certification Authority console.

This process must be repeated for all pending Key Recovery Agent certificates .When the certificate is issued, the CA publishes the certificate to the CN=KRA,CN=Public Key  Services,CN=Services,CN=Configuration,DC=ForestRootDomain container inside the CA object name. Publication in this container allows the Key Recovery Agent certificate to be added to the configuration of an enterprise CA in the forest, enabling key archival.

 

Installing and Exporting the Key Recovery Agent Certificate

Once a certificate is issued, the Key Recovery Agent certificate requestor can complete the installation by performing the following process:

  • Log on to the same windows machine using the account KRA1_CA_NAME. Open Internet Explorer at the same computer where the original request was submitted.
  • In Internet Explorer, open the URL http://CertSrvDNS/certsrv.On the Welcome page, click the View the Status of a Pending Certificate Request link.
  • On the View the Status of a Pending Certificate Request page, click the Key Recovery Agent Certificate (Date and Time) link. On the Certificate Issued page, click the Install this Certificate link.
  • In the Potential Scripting Violation dialog box, accept that the Web site is adding a certificate to your computer by clicking Yes.
  • Ensure that the Certificate Installed page appears, indicating that the certificate has been installed successfully. Close Internet Explorer.

Exporting the certificate and private key

Once you successfully enroll the Key Recovery Agent certificate, it is recommended that you export the certificate and private key to a PKCS #12 file and remove the key material from the hard drive of the computer where the request was performed. This process allows key recovery to take place at any computer where the private key is imported. It also ensures that the private key no longer remains on the computer where the request was performed.

Note: On the Export File Format page, click Personal Information Exchange—PKCS #12 and enable the following check boxes:

  • Include all certificates in the certification path, if possible
  • Enable strong protection
  •  Delete the private key if the export is successful

Enabling a CA for Key Archival

The following procedure enables key archival at an enterprise CA:

  • Log on at the enterprise CA as a user assigned the Manage CA permissions (known as a CA Admin).
  • On the Start menu, click Administrative Tools and click Certification Authority.
  • In the console tree, right-click the CA name and click Properties.
  • In the CA name Properties dialog box, click the Recovery Agents tab.
  • On the Recovery Agents tab, click Archive the Key; in the Number of Recovery Agents to Use box, type 1; and click the Add button.
  • In the Key Recovery Agent Selection dialog box, select the one or more Key Recovery Agent certificates and click OK.
  • In the CA name Properties dialog box, click Apply. When you click the Apply button, the CA performs a certificate validation test against each designated Key Recovery Agent certificate. If any certificate fails the validation test, the failure is designated once you restart Certificate Services.
  • In the Certification Authority dialog box, click Yes to restart certificate services.
  • On the Recovery Agents tab, ensure each added Key Recovery Agent certificate’s status is reported as Valid and click OK. You might have to close and reopen the CA Name Properties dialog box to see the change in certificate status.

The CA is enabled for key archival and can now issue certificates based on certificate templates that enable key archival.

Enabling Key Archival in a Certificate Template

Once the CA is enabled for archival, you can create and publish certificate templates that enable key archival. To enable key archival in a certificate template, the first thing that you must do is set the purpose of the certificate template to either Encryption or Signature and Encryption. Key archival is only possible for certificate templates with these purposes. In fact, if the certificate template’s purpose is Signature or Signature and Smart Card Log xpon, it is not possible to enable key archival for the certificate template. Once you define the purpose of the certificate template as Encryption or Signature and Encryption, the following properties must be configured on the Request Handling tab of the certificate template:

  • Archive subject’s encryption private key. Enable this check box.
  • Allow private key to be exported. Enable this option if you want to allow manual export of the certificate’s private key by the holder of the private key. This option is also required if the certificate will be requested by Windows 2000 clients by using the Certificate Services Web Enrollment pages.
  •  CSP. Select a CSP that enables key export. For example, a smart card CSP might not allow key export and archival.

Performing Key Recovery

Just a quick reminder of the content of the portion of the CA database used for key archival. This portion contains what is called as BLOBs. A BLOG is a combination of the user private key encrypted with a random symmetric key + the symmetric keys  themselves encrypted with the public key of one or more KRA.

Key recovery can be performed from the command line using the certutil.exe utility [or from the GUI using the Key Recovery tool (krt.exe) from the Windows Server 2003 Resource Kit]. I prefer the certutil option.

The certutil.exe command is used by both the certificate manager and the key recovery agent when key recovery is performed from the command line.

  • The certificate manager first determines the serial number of the affected certificate by viewing the properties of the certificate in the Certification Authority console.
  • Once the serial number is known, the certificate manager can extract the encrypted BLOB file by running certutil –getkey SearchToken OutputBlob in a Command Prompt window at the CA.
  • The SearchToken can be the serial number of the certificate, the Common Name of the certificate, the Thumbprint of the certificate, the certificate requestor’s user account name (domain\username),or the requestor’s User Principal Name (UPN) (user@domain.com). The OutputBlob is a file name for the output file.
  • The key recovery agent can then log on and use the certutil –recoverkey OutputBlob PKCS#12File command to recover the private key from the BLOB file into a PKCS #12 file. This process defines the file name and sets a password on the PKCS #12 file.
  • Now the resulting PKCS#12 file can be transported to the user and then imported by the user at his or her computer, allowing access to the private key at the computer.

PKI Certificate Services – Auto Key Archive

Hi everyone, i want to spend sometime explaining what is key archive in Microsoft Certificate Services.

When you issue a certificate, do you need to archive(backup) its private key ? The answer is : (Never) for signing certificates and (It Depends on your requirements) for encryption certificates.

For encryption certificates, suppose you are issuing an encryption certificate so your users can use EFS or S/MIME. What happen if they lost their certificate? Well, you will be the hero if you configured the certificate template to archive keys. This means that for every encryption certificate issued from the CA using this template, the CA will keep a copy of the private key.

So, when you create a certificate template, you will have an option to (archive) that certificate in the CA database.

Certificate_Template_archive_232422

The tricky thing, is that when an application request a certificate, the machine from which the certificate request is requested, is the same machine from which the private and public keys of the certificate is created. In other words, the private key of the certificate is created on the requester machine and not on the CA. What will happen next is that the machine will send the Public key to the CA so that the CA will sign the public key. The private key will Never leave the requester machine.

So when you enable key archival on the CA, a new way for issuing private keys and public keys will be followed. Even then , the private and public keys are created on the requester machine and not on the CA. Then the machine will send the public key so that the CA can sign it, and then will send the private key to the CA to archive it.

I will describe how this process works :

Certificate_AutoKeyArchival_%2324

  • The CA configured for Key Archival will issue a special short lived certificate named (CA Exchange Certificate). The CA exchange certificate is issued by the CA itself where the subject and issuer are almost the same. However, the subject contains a suffix to distinguish the certificate from a root CA.
  • The client makes an authenticated Distributed Component Object Model (DCOM) connection to the CA and requests the CA’s Exchange certificate (encryption certificate).
  • The CA sends the CA Exchange certificate to the client computer.
  • The client performs the following tests on the CA Exchange certificate:
    1. Verifies that the CA Exchange certificate is signed by the CA’s signing certificate. This ensures that the private key is being sent to the correct CA and only the intended CA can decrypt the private key.
    2. Performs a certificate validation and revocation status check on the CA Exchange certificate.
  • The client encrypts the private key corresponding to the request with the CA exchange certificate public key, builds a CMC request, and sends a CMC full PKI request to the CA.  (The request contains both the private and public key of the user) .After the CMC request is ready and encrypted with the CA Exchange certificate , the user sign the request with his public key.
  • The CA validates that the encrypted private key is the matched key to the public key in the CMC request. To do this, the CA encrypts randomly generated data with the public key in the request, and then decrypts the data with the private key passed in the unauthenticated attributes of the CMC request. The decrypted data is verified against the original random data. If any of the validation steps fail, or if the data does not match, the request is rejected
  • The CA validates the signature on the request with the public key in the request to ensure that the contents of the request are not modified.
  • The CA encrypts the user request’s private key with a random 3DES symmetric key and then encrypts the symmetric key with one or more Key Recovery Agent certificate public keys defined in the CA’s properties.
  • The CA saves the encrypted key BLOB—which contains the encrypted private key and the symmetric key encrypted with one or more Key Recovery Agent certificate’s public keys—to the CA database.
  • The CA processes the certificate request normally and responds to the client with a CMC full PKI response containing the certificate issued to the requester.

 

Requirement for Key Archive :

  • One or more users must acquire a certificate with the Key Recovery Agent application policy or the Enhanced Key Usage (EKU) object identifier (OID).This certificate allows the private key holder to decrypt private key material stored in the CA database. By default, the Key Recovery Agent certificate template requires certificate manager approval for issuance to ensure that only authorized personnel receive the Key Recovery Agent certificate.
  • The CA must be configured and enabled for key archival. In the CA’s properties, you must designate one or more Key Recovery Agent certificates that the CA must use to encrypt the private keys archived in the CA database. If at least one Key Recovery Agent certificate is designated, key archival is enabled at the CA (once Certificate Services is restarted). 

Important   All designated Key Recovery Agent certificates must be valid. If any of the Key Recovery Agent certificates are revoked, or fail any certificate validation test, key archival is not possible at the CA and certificate requests that require key archival will fail. 

  • A certificate template is enabled for key archival.

Remove Expired CRLs

By default, a CA will maintain an expired CRL in the database and will keep this CRL also in the directory at the last known CDP publication point for historical purposes. Once the key of a CA expires, the CRL is published one final time and no additional changes are made to that CRL. A best practice is to maintain this CRL in the CA database for long-term validation and audit purposes. However, it may be removed by using the following command:

certutil –setreg ca\CRLFlags +CRLF_DELETE_EXPIRED_CRLS