By replacing the certificate, your browser will not warn you anymore because of untrusty certificate and you get stronger security.

Requirements

To follow this topic, you need a working PKI based on AD CS. The root and intermediate certificates must be distributed on your computer. You need also a working vCSA 6.5u1 with SSH and bash enabled.

Generate a certificate request

First of all, connect to the vCSA by using SSH and launch the bash by typing Shell. Then run /usr/lib/vmware-vmca/bin/certificate-manager. On the first prompt, choose option 1.

Enter administrator credentials and choose again the number 1.

Then specify the following options:

• Output directory path: path where will be generated the private key and the request
• Country: your country in two letters
• Name: The FQDN of your vCSA
• Organization: an organization name
• OrgUnit: type the name of your unit
• State: country name
• Locality: your city
• IPAddess: provide the vCSA IP address
• Email: provide your E-mail address
• Hostname: the FQDN of your vCSA
• VMCA Name: the FQDN where is located your VMCA. Usually the vCSA FQDN

Once the private key and the request is generated, type the following command in order to connect with WinSCP to your vCSA.

Download WinSCP from this location and install it. Configure the connection as the following:

Once connected to your vCSA, download the vmca_issued_csr.csr file.

Sign the request with ADCS

Open the certification authority console and right click on the name of your CA. Select All Tasks | Submit new request…. Then select the CSR file you have downloaded from vCSA.

Then navigate to pending request and right click on the request. Select All Tasks | Issue.

Now navigate to issued certificate and double click on the certificate you just issued. Then navigate to Details | Copy to file.

Export the certificate in Base-64 encoeded X.509 format.

With WinSCP, copy the signed certificate and the CA certificate to the vCSA.

N.B: If your PKI is based on a multi-tier (Root CA and Sub Cas), you need to concatenate each CA certificate of the certification chain in a .PEM file.

Replace vCSA 6.5u1 certificate

Run again /usr/lib/vmware-vmca/bin/certificate-manager and select option 1. Specify administrator credentials and this time select option 2.

Then specify the signed certificate, the private key and the CA certificate (or a concatenated PEM file with all CA certificates, in case of multi-tier PKI).

If the certificate is good, you should see that each service is updated. When all service is updated, the vCSA restart.

N.B: I have seen in production that the certificate replacement doesn’t work because of plugin. In this case, you’ll see which service make the issue. Disable the plugin and try again.

Once vCSA has restarted, connect to the Web Service by using a Browser. You should see your custom certificate as below:

The post Replace vCSA 6.5u1 certificate by an ADCS signed certificate appeared first on Tech-Coffee.

In the last part, we have created a certificate template for WinRM over HTTPS. Now the Sub CA is able to respond to enrollment request. To remember, enrollment is the process for a client to obtain a signed certificate. The client which asks for a signed certificate is called the enrollee.

In this part, we will see how to obtain a certificate from the certificate template called WinRM.

Enrollment

To make an enrollment, open mmc.exe and click on File and Add/Remove Snap-in:

On the left menu, select Certificates and click on Add. There are three types of snap-in to manage certificates:

• My user account: manage certificates related to your account (personal certificate);
• Service account: manage certificates related to a service (IIS, LDAP etc.);
• Computer account: manage certificates related to the computer (or remote computer).

I select computer account for WinRM using.

Then right click on personal store (or certificates as below) and select All Tasks and Request New Certificate.

On the first screen, click on Next.

Select the Active Directory Enrollment Policy and click on Next.

Select the certificate template that you have configured previously. So I select the certificate template WinRM that I have configured on the previous part.

And that’s all. The enrollment is in progress.

At the end of the enrollment, you should have the certificate in your personal store.

Auto-Enrollment

With Active Directory Certificate Services, it is possible to make Auto-Enrollment to avoid manual steps as above. In this way all machines where you have set auto-enrollment will obtain a certificate automatically. To configure auto-enrollment, your certificate template must have the security permissions set correctly (view previous part).

Next setting is set in GPO. So open gpmc.msc from a domain controller or console server and create a new GPO.

Edit the GPO and navigate to Computer Configuration > Policies > Windows Settings > Public Key Services. Edit Certificate Services Client Auto-Enrollment policy. Set settings as below.

Next, apply the GPO where you want servers make auto-enrollment. On my side I want that all my servers obtain a certificate to configure WinRM over HTTPS everywhere. So I link the GPO on domain level.

Next I’m connecting to a server. I open a mmc as above. As you can see, no certificate are present on this server.

So I run a gpupdate in order to refresh GPO on this server. My GPO is applied and I obtain certificates. I have another certificate for OCSP signing. It is because I set another certificate template to auto-enroll OCSP server (for the next part J).

If I open a certification authority console on the Sub CA and I navigate to issued certificates, I obtain that:

So it is working well. Now you know how to deploy a PKI and how to deploy a certificate. No excuse to not use HTTPS, IPsec or other way to encrypt communicationJ. Next part I will talk about OCSP responder.

The post Public Key Infrastructure Part 7 – Enrollment and Auto-enrollment appeared first on Tech-Coffee.

Certificate Revocation List

As seen in previous the part, Certificate Revocation List contains revoked certificate IDs (only non-expired revoked certificate). To determine if a certificate is revoked, the client downloads the CRL and verify if it is not in the CRL. The CRL is cached by the client for the duration of the validity period. By default, a CRL validity period is 1 week. That means that the CRL is updated on the Certificate Distribution Point (CDP) every week. So it can be a security issue because if a certificate is revoked during the validity period of the CRL, this last will not be updated on CDP and the client will not know that the certificate is revoked.

So if you are using only base CRL, do not configure a longer validity period to reduce the security issue period. In the other hand, do not publish too often the CRL to avoid network overload especially if your CRL is large. You have to find a golden mean.

Delta CRL

A delta CRL contains revoked certificate IDs (only non-expired revoked certificate) since the last CRL has been published. To determine if a certificate is revoked, the client downloads the CRL (will be cached) and the Delta CRL. By default the CRL is published every day.

Delta CRL is used when the CRL becomes very large. In this case the CRL is published less frequently and Delta CRL is downloaded more frequently.

CRL overlap

When using CRL overlap, two CRL is published at different times. For example, suppose that CRL has a validity period of 4 days. So the first CRL is published and the second will be published two days after.

CRL overlaps is used to be sure that a new CRL is available before that the first CRL is expired. When you store the CRL in Active Directory and you have many sites, the CRL propagation depends on DFS replication. So it is necessary to allow time for replication. So in this case, CRL overlaps can be used. By default on Active Directory Certificate Services solution, the overlap period is 10% of the CRL lifetime and 12 hours at maximum.

Configure CRL

Below commands configure the CRL validity period to 6 days:

certutil -setreg CA\CRLPeriodUnits 6
certutil -setreg CA\CRLPeriod "Days"

 Below commands configure the Delta CRL validity period to 1 days:

certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil –setreg CA\CRLDeltaPeriod "Days"

 Below commands configure the overlap period to 2 hours:

certutil -setreg CA\CRLOverlapPeriod "hours"
certutil -setreg CA\CRLOverlapUnits 2

The post Public Key Infrastructure Part 4 – Configure Certificate Revocation List appeared first on Tech-Coffee.

In this part I’m going to install a Public Key Infrastructure consists of an offline Root CA and an online Sub CA. The offline Root CA will be installed on a server that is not member of Active Directory and will be shut down after installation. The Sub CA will be an enterprise CA because it is joined to Active Directory and always online. My Root CA server is called VMPKI01 and the Sub CA server is called VMPKI02.

This topic is part of a series of articles about Public Key Infrastructure. If you are not comfortable with AIA, CA, CDP and anything about PKI I recommend you to read previous parts of this series.

Active Directory Certificate Services role installation

This part is run on every Certificate Authority server (VMPKI01 and VMPKI02).

First, open the Server Manager and select Add Roles and Features as below.

When you are on Select Server Roles screen, select Active Directory Certificate Services.

On Select role services screen, select only Certification Authority.

To finish click on install.

Root CA configuration (VMPKI01)

Certification authority service configuration

Open the Server Manager and click on the flag. Select Configure Active Directory Certificates Services as below.

On the first screen of the AD CS Configuration, It informs you that install a Standalone Certification Authority, you need an account member of the Administrators group.

Tick the Certification Authority check box and click next.

On the Setup Type screen, you have no choice : you must select Standalone CA.

On the CA Type screen, select Root CA and click next.

On Private Key screen, select Create a new private key. The other options are used when you want to restore a CA after a disaster.

On the next screen, I advise you to set at least a key length of 4096 and use at least SHA 256 (MD5 and SHA-1 are vulnerable to collision).

Next, specify a common name for your CA. I choose to not change this parameter.

On Validity Period screen, select a validity period for the Self-Signed certificate using to sign certificates for Sub CA. In best pratices, this type of certificate should have a validity period between 10 and 20 years.

Next, choose the database locations. It is recommended to store the database on a separate disk.

To finish, click on configure to run the CA configuration.

Now you can open Certification Authority console (as below).

Extensions configuration (AIA and CDP)

Before signing any certificates, it is necessary to configure the CDP and the AIA extensions. Every certificate you sign before you configure these extensions will not have CDP and AIA information and you will must resign them. To configure CDP and AIA open Certification Authority console and right click on the CA Name (as below). Select Properties

Navigate to Extensions tab. On CRL Distribution Point (CDP) menu we have some settings to modify. First I delete all CDP except LDAP.

I add a CDP located to D:\CRL. I use variable to construct CRL name. In this example the CRL will be called VMPKI01-CA.crl

Verify that the previously CDP added have the publish option ticked for CRL and Delta CRL as below.

For the LDAP CDP, make sure that this options are configured as below. The first checkbox is useful to include the Active Directory path directly in CRL to simply publishing manually. The second option add the CDP extension to the certificate. This extension is used by servers to download the CRL.

Next I navigate to Authority Information Extension (AIA) menu. As CDP, I remove every location except LDAP. Verify that option Include in the AIA extension of issued Certificates is ticked for LDAP location. The server will download the certificate chain from the path included in AIA extension.

Next I add my custom path to store the CA certificate.

Once extensions are set, click on apply. You will be asked to restart the Certificate Services. Select yes.

Now I try to publish a CRL to validate my settings. For that right click on Revoked Certificates, select All tasks and publish.

Now that my CRL is published I navigate to D:\CRL and as you can see below, I have my CRL.

CRL and Certificate Validity period

The Root CA is used to sign the CA certificate from Sub CA. So the Certificate and CRL validity period can be increased. So open the registry key HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>. To modify the signed certificate validity period, edit ValidityPeriodUnits and set this key to 20. Because ValidityPeriod key is set to Years, certificates that will be signed by my Root CA will have a validity period of 20 years. You can do this with these commands:

certutil -setreg ca\ValidityPeriodUnits 20
certutil -setreg ca\ValidityPeriod "Years"

Next the CRL validity period can be increased also because this CA will sign certificate only of Sub CA. So few revocation will be performed. So edit CRLPeriodUnits and set this key to 12. Because CRLPeriod key is set to Weeks, the validity period of the Root CA CRL is 12 weeks. You can do this using these commands:

certutil -setreg CA\CRLPeriodUnits 12
certutil -setreg CA\CRLPeriod "Weeks"

To finish, you have to restart CertSvc service (net stop certsvc && net start certsvc)

Variables configuration

Before when we have set CDP and AIA extensions we have seen variable. There are also variables for the Distinguished Name in Active Directory where to store information (for example LDAP CDP). Because my Root CA is not a member of an Active Directory, it can’t know the Distinguished Name (DN) in Active Directory. So it is possible to define it manually with certutil command:

Certutil –setreg ca\DSConfigDN "CN=Configuration,DC=My,DC=Domain"

Below an example in my environment:

Next, you have to restart CertSvc service (net stop certsvc && net start certsvc). To view if the configuration is good, publish again the CRL and open it. In the General tab, you should see Published CRL Location field. If the value of this field contains the DN that you have specified previously it is good:

Publish Root CA CRL and AIA to Active Directory

The first time, you have to connect with an enterprise admin account to publish certificate and CRL in Active Directory.

To finish the Root CA configuration, it is necessary to publish the CRL and the Root CA certificate in Active Directory. For that I have copied the Root CA certificate (crt file) and the CRL file to VMPKI02. Next I have run the below commands:

Publish CRL: certutil –dspublish –f <CRLFile> <CAName>

Publish CA Certificate : certutil –dspublish –f <CACertificateName>

Now the basic configuration of the Root CA is done. It is time to set the Sub CA.

Sub CA configuration (VMPKI02)

You have to connect with an enterprise admin account to install the enterprise Sub CA.

Connect to the Sub CA server and open the Server Manager. Select Configure Active Directory Certificate Services as below.

On the first screen, you can see that an Enterprise Admins account is needed to install an Enterprise Certification Authority

On Role Services screen, select Certification Authority and click on next.

On Setup Type screen, select Enterprise CA and click on next.

On the next screen, select Subordinate CA.

On private key screen, select Create a new private key. Other options are used to recover the CA after a disaster.

On the next screen, I advise you to set at least a key length of 4096 and use at least SHA 256 (MD5 and SHA-1 are vulnerable to collision).

Next specify a common name for your CA and the distinguished name. I choose to let default parameter.

Next, specify where to store the certificate request and click on next.

Next, choose the database locations. It is recommended to store the database on a separate disk.

Click on configure to run the CA configuration.

Submit the CA certificate request

First copy the request file that is generated from your Sub CA to the Root CA.

Open the certification authority console, right click on the CA Name. Select All tasks and Submit new request. Then specify the path to the CA certificate request.

Once the request is submitted, navigate to pending requests and right click on the request. Select all Tasks and Issue.

Once the CA certificate is issued, navigate to Issued Certificates and right click on the certificate and select open.

Navigate to details tab and click on Copy to File.

After that, the export wizard is opened. On File Format screen select DER encoded X.509 (.CER).

Specify a location to store the CA certificate. I choose to store it directly on Sub CA server.

CA certificate installation on Sub CA

Open the Certification Authority console and right click on CA name. Select All tasks and install CA Certificate. Select the certificate that you have previously exported.

Once the CA certificate is installed, you should start the Certificate Services.

Extension configuration

As Root CA, CDP and AIA should be set first. I configure a CDP on D:\CRL where I publish only CRL.

Make sure that the LDAP CDP is configured as below.

On AIA menu, I set a custom location to store certificate on D:\AIA. Make sure that LDAP location is set as below.

Click on apply and the service should restart. Now you can open PKIVIEW.msc:

Now you have a basic PKI ready to sign certificates. It is a basic configuration. In the next part of this series of articles we will see more in details CRL  configuration.

The post Public Key Infrastructure Part 3 – implement a PKI with Active Directory Certificate Services appeared first on Tech-Coffee.

Public Key Infrastructure

Certificates

As you have seen previously, encryption and signature operation are performed with public and private key. These two keys are mathematically related. So when an entities (users or computers) want to receive encrypted or signed data, it generates a private key and send the public key to its correspondent. The correspondent performs the same process. This is called the Key Exchange.

The first problem of key exchange, is that the key must not be duplicated by malicious guy. So it is necessary to create a secure channel to make the key exchange. The solution can be physic with a diplomatic bag for example. In 1976 a popular person called Diffie Hellman published a secure key exchange protocol called DH key exchange (Diffie Hellman key exchange). Thanks to DH, a secure channel can be used for the key exchange. But this protocol doesn’t resolve the second problem: how to be sure that the public key belong to the owner that claim to be?

This is why digital certificate (called sometime public key certificate) has been created. A certificate is a digitally signed document containing the entity information (such as name, postal address, E-mail etc.). In this way, it is possible to be sure that the public key belongs to an entity.

Usually the certificate is signed by a trusted third party called Certificate Authorities. A certificate has an expiration date, information about key using (encryption, signature or both) or the certificate using (authentication server, E-mail signing etc.).

Figure 1: Example of a certificate: outlook.com

The above certificate (figure 1) is delivered to the entity mail.live.com by a certificate authority called VeriSign. This certificate has a validity period from May, 21^st 2013 to May, 23^rd 2013.

Figure 2: Example of certificate: detailed information

Certificate contains other details such as:

• The asymmetric cryptography algorithm;
• The subject Alternative Name that contains other known identity of the entity;
• The hash algorithm;
• Key usage;
• The Certificate Revocation List (view d. Certificate Revocation List section);
• The Authority Information Access (view Authority Information Access).

Certificate is based on a standard called X.509 to be sure that the certificate is interoperable. This standard defines a certificate structure. For example the entity and certificate authority identity must be distinguished name as LDAP protocol (X.501 standard). For more information about X.509 please read RFC 2459 (https://www.ietf.org/rfc/rfc2459.txt).

Certificate Authority

A Certificate Authority called CA, is the trusted third party that digitally signed certificate. So it is the CA that approves certificates that ensures that public key belong to an entity. So it is a critical component in security.

Because a CA digitally sign certificates, it needs also a public and a private key and so a certificate. This certificate can be self-signed by the CA or signed by a top CA. When a CA uses a self-signed certificate, it is called a Root CA while in the other case it is a subordinate CA (called also Sub CA or intermediate CA).

A certificate authority performs mainly these actions:

• Issue certificate requests by signing them;
• Revoke certificates for many reasons (end of validity, compromised key etc.).

A Public Key Infrastructure (PKI) can be composed from one to many Certificate Authorities. Usually at least two certificate authorities participate to a PKI: one Root CA and one Sub CA. A PKI is always composed of one Root CA. The others CA are Sub CA.

Root CA or Sub CA can sign CA certificates or client certificates but as best practices, it is recommended that:

• Root CA should sign only CA Certificates;
• Sub CA should sign for CA certificates OR client certificates but not both.

For example, a PKI architecture can seems as Figure 3.

Figure 3: Example of PKI design

The Root CA signs the CA certificate for Sub CA Users and Computers. The Sub CA users signs Sub CA certificates of Marketing and Engineers. To finish Sub CA marketing and Engineers sign certificates for users while sub CA computers signs certificates for computer.

When a user or a computer uses a certificate, it must verify the validity of its certificate authority and all CA on top until the Root CA: it is called the chain of trust.

Chain of trust

All certificates from Root CA to end-users either a computer, a user, a CA or other entity, is called the chain of trust. When a certificate is used, each certificate in the chain of trust must be checked. Figure 10 is a screenshot of outlook.com certificate on certification path tab. This chain of trust is composed of:

• A Root CA called VeriSign;
• A Sub CA called VeriSign Class 3 Extended Validation SSL SGC CA;
• The end-user certificate.

Figure 4: Chain of trust of outlook.com certificate

When a user connects to outlook.com, he verifies that the certificate is valid from the intermediate CA. But the user must verify also the validity of the intermediate CA certificate from the Root CA VeriSign.

Certificate Revocation List

As I said previously, certificate authorities can revoke a certificate. When a certificate is revoked, it must be no longer useable. This is why Certificate Revocation List (CRL) exists. Each time a certificate is revoked, its ID is added to a file called CRL. This CRL is signed by the CA itself.

To be available to entities which use certificate, CRL is published on distribution point called CDP (CRL Distribution Point). It can be a Web Server, an LDAP server such as Active Directory or a share. These CDP are added to the certificate in CDP extension. Many CDP can be referenced in the CDP extension.

Figure 5: CDP extension of outlook.com certificate

When a client checks a certificate validity, it downloads the CRL referenced in certificate CDP extension. If several CDP are included in CDP extension, the client will download the CRL from the first location. If the client can’t download the CRL from this location, it will attempt with the next CDP included in CDP extension and so on. The CRL is downloaded and cached by the client for the validity period of the CRL.

For example if a CRL has a validity period of 3 days, the CRL will be cached by the client for 3 days. Once 3 days have passed, the client download again the CRL.

Moreover, more the CRL validity period is longer, more you take security risk. If a certificate is revoked when the client has cached the CRL, the client will not know that the certificate is revoked. This topic will be discussed in Design Part.

CRL can become a very large file if your organization revokes regularly certificate. It can be a problem for your bandwidth and sometime because the CRL is very large, the threshold time limit to download CRL can be reached. That result that the revocation checking process fails. To limit these issues, Delta CRL can be used.

Delta CRL is a partial CRL that contains revoked certificate IDs since the last CRL has been published. In this way CRL validity time can be lengthy and the publication of Delta CRL can be performed regularly. So the client will download the CRL for a greater period of time and will download only Delta CRL most of the time. That result to save bandwidth.

Figure 6: Outlook.com certificate CRL

As you have seen, CRL presents some disadvantage:

• CRL can become a large file that result bandwidth issue;
• The validity period must be balanced between bandwidth saving and security risks;
• Depending on where the CRL is located, some client can’t access to it (for example if CRL is hosted on Active Directory, usually the internet client can’t download it).

To resolve CRL disadvantage, an alternative protocol can be used: Online Certificate Status Protocol.

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) is a standard protocol used to validate the certificate. OCSP uses ASN.1 as data structure. Usually and in Microsoft world, OCSP uses HTTP to transport messages. OCSP uses the model client/server and the OCSP server is called OCSP responder. Sometime OCSP responder is also called Validation Authority (VA).

When an OCSP responder is asks about certificate validity, it indicates just the certificate status. So the data transmitted over network between OCSP responder and client are always the same, independently of the number of revoked certificates.

Except some case, OCSP relies on CRL published by CA to determine the certificate status. But when an OCSP responder is used, only it will download CRL and no longer clients. So the CRL validity period can be reduced regardless bandwidth saving.

The OCSP responder signs each response made to client with its own private key. So the integrity of this key must be checked by the client after that OCSP responder sends a status.

Because OCSP is usually based on HTTP, the client doesn’t cached a revoked certificate database as CRL process. So each time a certificate must be validated, a request is sent to OCSP responder. So in large PKI infrastructure, OCSP responder can be overloaded and so requires load-balancer and geographical deployment to ensure high-availability.

Authority Information Access

To validate a chain of trust, each certificate in this last must be checked. To validate certificates, the client must access to it to be sure that the certificate is in validity period and to find related CRL or OCSP responder.

Authority Information Access (AIA) is used to locate CA certificate. AIA contains the CA certificate path and is referenced in certificate AIA extension. AIA can indicate CA certificate path over HTTP, LDAP or share.

Figure 7: AIA extension in Outlook.com certificate

Public Key Cryptographic Standards

Public Key Cryptographic Standards (PKCS) are a set a “standards” to describe some cryptographic process. I have written the word standard between quote because it is not really standards. PKCS specifications are published by RSA Security (belong to EMC since 2006) company and only a few of them are taken up by the normalization agency.

PKCS specifications are numbered after a hash. For example the DH key exchange is called PKCS#3. In this part I will not present you all PKCS specification. Only the most important to understand PKI are described. For more information, you can visit https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-rsa-cryptography-standard.htm.

PKCS#7 (RFC 2315)

PKCS#7 is standardized by the IETF as RFC 2315. This standard defines syntax for cryptographic message either to sign or encrypt data. This standard also describes how to respond to a PKCS#10 message.

PKCS#7 certificate is based on PKCS#7 specification and it is a X.509 certificate as described previously. PKCS#7 certificates can have these file extensions: .p7b, .p7c, .der, .cer, .crt or .pem. On Microsoft environment, .cer and .der are mainly used.

PKCS#10 (RFC 2986)

PKCS#10 is standardized by the IETF as RFC 2986. This standard describes the certificate request process. Usually this request is sent to a certificate authority. The CA can sign the request and so issue a PKCS#7 certificate. On Microsoft environment, the certificate request file has .req, .csr or .txt extension. On other environment, this file can be found with .p10 extension.

The certificate request contains the identity of the issuer and his public key. The certificate request is signed by the private key of the issuer.

PKCS#11

PKCS11 is an API for security token such as HSM (Hardware Security Module) or Smartcard. When you plug a smartcard on your Windows, the communication is done across PKCS11 API. Usually this API is added to system when you install the smartcard drivers.

PKCS#12

PKCS#12 specification describes how to store and transport safety private keys, certificates or other sensitive information. PKCS#12 file act as a container usually protected by password. Because PKCS#12 can store certificates, the chain of trust can be included in the file. On Microsoft environment, the PKCS#12 file extension is .pfx. On other environment it can be found as .p12 file.

The post Public Key Infrastructure part 2 – main components appeared first on Tech-Coffee.