Category Archives: Certificates

Renew SSL certificate for ADFS URL

This document outlines the steps to renew the SSL certificate for ADFS claims providers federation metadata URL

1) To take the application ID and the certificate hash run the below command.

netsh http show sslcert


copy only application id value. This we require for the certificate renewal. Better to take a copy of this results.

2) Run this command to see the ADFS listners

netsh http show urlacl 


This is just to take a copy of the ACL url’s before the certificate renewal. This part is so sensitive because ADFS will have some URL reservations in the HTTP.SYS. This will help us just in case if we face any issues after the certificate renewal.

3) Delete the old certificates –

$Command = “http delete sslcert”
$Command | netsh

$Command = “http delete sslcert”
$Command | netsh

$Command = “http delete sslcert hostnameport=localhost:443”
$Command | netsh

$Command = “http delete sslcert”
$Command | netsh

4) Delete the old hostIP and port entries:

$Command = “http delete sslcert hostnameport=”
$Command | netsh

5) Now we can add the new certificates:


Take the APP id which was noted down in the step 1

Take the certificate Hash – This can be taken from the new certificate thumbprint

example below –  remove all the spaces and copy the new certificate hash value.


$guid = “paste the appid here”

# Cert Hash
$certhash = “paste the certificatethumbprint”

To renew actual metadata URL:

$hostnameport = “”
$Command = “http add sslcert hostnameport=$hostnameport certhash=$certhash appid={$guid} certstorename=MY sslctlstorename=AdfsTrustedDevices clientcertnegotiation=disable”
$Command | netsh

To renew localhost:

$hostnameport = “localhost:443”
$Command = “http add sslcert hostnameport=$hostnameport certhash=$certhash appid={$guid} certstorename=MY sslctlstorename=AdfsTrustedDevices clientcertnegotiation=disable”
$Command | netsh

To renew Device Registrations:

$hostnameport = “”
$Command = “http add sslcert hostnameport=$hostnameport certhash=$certhash appid={$guid} certstorename=MY clientcertnegotiation=enable”
$Command | netsh

The above is required because Changes were made in ADFS on Windows Server 2012 R2 to support Device registration and happens on port 49443.

$hostnameport = “”
$Command = “http add sslcert hostnameport=$hostnameport certhash=$certhash appid={$guid} certstorename=MY sslctlstorename=AdfsTrustedDevices clientcertnegotiation=disable”
$Command | netsh

The above is also  required for device registration service.

Hope this helps.

How certificate revocation works

For any web application which is hosted externally will be SSL encrypted.To establish a secure connection they require a certificate.Basically these certificates have a Public key certificate which has a digital signature  for them so that it  can be trusted  for the name, address , organization it has in the certificate by the client.

In a typical public-key infrastructure (PKI) scheme, the signer is a certificate authority (CA), usually a company which charges customers to issue certificates for them.Browsers ensure user safety by requesting certificate information from the vendor instead of from the web application server.

The job of a CA who issues the certificate is not to just issue the new  certificate requests . It needs to provide the certificate revocation information for all the requests it is receiving from the clients.

In this article we will have a look at how certificate revocation works.

Below are the types of  certificate revocation check that can be configured

1) CRL Distribution. –  Certificate Revocation List.

2) OCSP – Online Certificate Status Protocol.

3) OCSP Staple .

Both the configuration (CRL & OCSP)  needs to be done  on the certificate authority properties extension tab as shown below


CRL distribution is the core component of the certificate revocation the latter two options are indirectly and totally dependent on the CRL.

The CRL configuration has below  components:

Base CRL – This will contain the whole complete list of revoked certificates (non-expired). so what ever the revoked certificates we have will be present here.

An example below of how it will show in the CRL  and will show all the revoked certificates

Delta CRL – This will contain only the list of revoked certificates which got from the last CRL distribution points. So this will not have all the revoked certificates.

An example of delta CRL

CDP(CRL distribution points) – This CRL distribution point is the place where the Certificate Authority publishes all the certificate information. So the base CRL and the delta CRL gets information from this place only.

A real time example of CRL distribution point wehn seen from the client side.


There are 2 types of CRL distribution points which can be configured:

LDAP – Not firewall friendly and complicated. We also need to allow LDAP port for this verification which is normally not feasible. Personally i don’t feel to allow my LDAP port accessed externally for this revocation process.

HTTP – This is easily accessible by all clients.Its very good if configured properly without exposing the internal name space. So basically we need to create a DNS records for the http url to publish ,create a virtual directory for the CRL distribution points and configure a file server.

The disadvantage of CRL’s is that the client has to search through the complete revocation list. More over they are updated periodically and chances are there the client might get wrong information until the next update happens on the CDP. Usually the browsers take more time to load all these certificates and then check the revocation for its required certificate.

OCSP : Online Certificate Status Protocol

With the OCSP the job has become very simple and easier. This removes the major disadvantage of CRL by allowing the client to check the certificate status of its only one which it owns by providing a serial number to the responder.

OCSP Client – This is the client responsible for querying the certificate check . This OCSP client is available from Windows vista and later versions of operating systems. Operating systems prior to these versions will be using the normal CRL check to validate the certificates. This client is responsible for  providing a serial number to the responder.

OCSP responder (web proxy) – This component is available from Windows 2008 server CA. Servers holding CA prior to this versions will be using the CRL to respond the
requestors. This will check the certificate status of the serial number provided by the client. Then it holds a cache entry of the requests that came so that it would be easier to provide them in future .
The OCSP client request process in shown below:
1) Client access the website via browser.
2) Client sends OCSP Request to a OCSP Responder (over HTTP) with the certificates serial number for which it requires verification.
3) OCSP Responder replies with a certificate status of either Good, Revoked or Unknown .



2 important things for OCSP configuration

1) The Online Responder service runs under the Network Service account. So we need to make sure it Network service has read permission.
2)  we need to enable the value id-pkix-ocsp-nocheck extension for the OCSP by running the below command.

certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

This extension is to avoid the circular revocation checking so that it will not verify the signing certificate from the OCSP requestor.

OCSP stapling:

With OCSP stapling, the web server downloads a copy of the vendor’s response which it can deliver directly to the browser. So the browser do not need to contact the CA seperately rather it will contact the application directly and get the certificate.

With OCSP stapling, the application periodically queries CA and caches a response which is then provided to the browser. By default this setting is configured when we configure OCSP .

The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ controls this behavior.

If we want to disable stapling then all we need to do is create a DWORD called RequestOCSP in the same location and set it to value 0.

A real time example of OCSP distribution point when seen from the client side


Hope this article gave some idea on how certificate revocation works .

Thanks & Regards

Sathish Veerapandian

MVP – Office Servers and Services 

Create private key and certificates for load balancer ,firewalls through Certificate Authority

All of the Load balancer’s require an SSL certificate since they use HTTPS as a front end listener for all of the services that are handled by them.
So basically a certificate is very much mandatory here to terminate the incoming connections and then decrypt the requests from the clients and sending them to the appropriate instances.
In order to install the SSL certificate on your load balancer , you must create a certificate request , submit them to a CA , get them signed by your internal CA or a third party trusted CA and then installing them on your load balancers.

Before creating a CSR, the applicant first generates a key pair, keeping the private key secret.
The CSR has the public key chosen by the requester. So in most of the cases these CSR gets generated from a web application and the private key is not shared and is stored in the application itself.

In most of the cases SSL certificate for these load balancers can be either a self-signed certificate or a trusted Certificate Authority (CA) certificate.

A self-signed SSL certificate is a certificate that has been signed by its own private key

A trusted CA is an SSL certificate that is signed by a CA’s private key

Though there is an option to create a self signed certificate,most of the load balancers recommends using only a trusted CA certificates since it is more secure than using self-signed certificates.

In this article we will have a look at generating a certificate through CA for a load balancer.

First in order to create the CSR request we need to login to the certificate authority (certsrv) and submit the CSR request with your internal IP of the load balancer

usually it is https://yourinternalCAserver/certsrv



Now select the 2nd option in the next page as below



Now select the 1st option as shown below


Next comes the main page where we need to provide the ip address of the load balancer as the common name for which it will generate the CSR from the CA server and submit to the CA.

In the name section we need to make sure that the IP address is specified

We need to make sure that we are selecting the option mark keys as exportable which will allow us to export the private and the public key (for giving the key pair) to the load balancer.

Also we need to make sure that we select the format as PKCS10



once the request is submitted you need to go to the home and click on  view request status


You will get the status of the pending requests as below


Once you click on this you can see this certificate will be issued to the CA for verification.

On a successful submission of this CSR this request will go to the CA in the pending queue and will show in the pending requests.

Then we need to go ahead and issue this certificate from the pending requests

Once the certificate is issued successfully you can go to the issued certificates and there we can see this certificate. When we double click on that certificate and in the general tab we will see an information that says you have a private key that corresponds to this certificate.



So this ideally means that the private key as well as the public for the load balancer is generated from the certificate authority in my example. And it was my CA who generated the private key and the CSR request.

Now  we need to export this certificate in the pfx format with the keypair (private & public) and then import them on the load balancer.

So now while exporting this certificate i need to export the certificate with the below option


Once exported we can install this certificate on the load balancer.


We need to be very careful while working with certificates .In the above method key-pair will be generated and this key pair should not be shared to any of the external parties. Sharing this key-pair to any of the third parties will easily compromise your whole network since they are load balancer certificates. Proper planning and understanding of the scenario according to your environment needs to be done before performing such kind of tasks.

Hope this helps !!


Sathish Veerapandian

MVP – Exchange Server

%d bloggers like this: