+1 971 231 5523 info@pkisolutions.com

The PKI Guy Blog

PKI Solutions Inc. The PKI Guy Blog

Certificate Validation Certutil Internet Explorer Offline CA PKI Revocation Watch Out

Ignore Revocation Checking – The bane of my existence!

As students in my PKI training classes know, one of the areas I am a vocal about is the blind use of the CRLF_REVCHECK_IGNORE_OFFLINE setting in a PKI environment. I am so adamantly against the use of this setting, I personally refuse to ever explicitly share or type the syntax to enable this nasty beast. Unfortunately this setting pops up in vendor documentation, software deployment guides and other “authoritative” sources that place customers at risk. It is a classic example of where companies have written software or guides based on what they did in their test environments and unknowingly expose their customers to a big risk.

First, let’s talk about what this setting is all about. In practice, RFC 5280 defines the use of revocation information to indicate which certificates have been marked as untrusted and should fail validation checks by systems checking certificates from that issuer. If revocation details can not be retrieved or verified, a certificate should be assumed invalid. This means the inability to find and use a valid revocation source will result in errors to the relying party (unless we are talking about apps like Internet Explorer).

So what happens to environments to cause them to use this CRLF_REVCHECK_IGNORE_OFFLINE settings? Often when something has broken in their environment – such as failure to renew the CRL of an offline CA or access issues to a Certificate Distribution Point (CDP). Environments wind up seeing an error message like:

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

So they search the Internet and find lovely nuggets of HORRIBLE advice that indicate “they too” had this problem and all they had to do to fix it was “run this command”. They then go on to show how to run the command to turn off revocation checking. If the CA is offline and the CRL wasn’t published properly or is expired, the fix is to republish the CRL. If the CDP location is inaccessible – fix the site! Don’t put a bandaid on a brain hemerage, fix the root cause.

The other place this issue comes up is software documentation and deployment guides – even from the largest companies. I have a plethora of documents and sites in my “to-do list” to contact and let them know the mistakes they are making in their documentation.

Take this one from VMWare and their documentation for VMWare Horizon 7 clients. If you look at step 12 you will see this doozy of a recommendation:

12. Enter the following command to ignore offline CRL (certificate revocation list) errors on the CA:

Say what? WHY would you ever recommend that to your customers?

My recommendation is to ALWAYS question any deployment, configuration or recommendation that has you running the command to turn off revocation checking.  It’s there for a reason – to protect you. Fight back, rise up and refuse to accept that it “must just have to be that way since XXXX is recommending it”.

Read More
  • April 20, 2017

Certificate Validation Internet Explorer PKI Revocation RFCs Watch Out

What Your Browser Doesn’t Tell You Can Hurt You – Revocation and Internet Explorer

One of the topics I have been using as an example of revocation checking behavior in my PKI In-Depth class is the interesting case of Internet Explorer (IE) and its revocation behavior. Let’s take a moment and have you think about your assumption of how IE is behaving when you go to a HTTPS (SSL/TLS) website. The general assumption is that the TLS certificate is downloaded from the web server, the URL entered is compared to the Subject/Subject Alternate Name extensions to ensure we arrived at the right site and haven’t been redirected. The browser should go on and validate additional information like validity period, key usage, and of course assembling the chain of certificates to ensure it comes from a trusted CA. It will of course check the revocation of that certificate, and any certificates in the chain above it. But what do you expect will occur if revocation checking fails? Such as being able to reach the revocation site, finding an expired CRL, a tampered CRL or an inactive OCSP Responder?

In my In-Depth class I use IE as an example of the principle that despite what a RFC may indicate SHOULD occur, applications are written at the discretion of the developer(s). Would you be surprised to learn that IE will ATTEMPT to check the revocation of the certificates for the TLS website, but if it encounters any errors, the default behavior is to NOT report an error to the user and just continue to load the website and show it as secure? Yup – that’s right, all an attacker would have to do it block your access to a CRL and IE will report the website as secure. The RFC states that revocation checking must succeed and if it doesn’t, you should assume the certificate is invalid until you can.

So why does IE do this? You can read more details in this old blog post at Microsoft – that surprisingly isn’t well publicized. It explains that Microsoft determined that possible connectivity issues may prevent IE from being able to reach revocation information so they decided to have it perform “soft” CRL checking. It will try to reach the CRL and if the CRL contains the serial number of the TLS certificate in question – it will report it as unsecure. However, if the CRL is expired, invalid or simply can’t be reached, no error message at all.

While this might be an acceptable (not in my opinion) option for home users who might be adversely affected by accidently certificate invalidation, I doubt most enterprises are willing to accept this risk. The surprising thing is that almost every organization I have worked with or trained, has never known that IE performs this “soft” CRL checking. They are often surprised that their browser has this default behavior – I was too, when I first found out.

Fortunately, this can be fixed through a Feature Control Key. Alright, let’s just call it what it is – a registry key!


There is a key to turn the feature on:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]


And a key to turn the feature off (return to the “soft” checking)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]


You can of course craft a Group Policy to push this out to your enterprise.

So let this be a lesson to make sure you make no assumptions about how your applications and systems are using and validating certificates. Trust but Verify I say! So what are you waiting for?

Read More
  • February 11, 2017

Certificate Templates Certificate Validation Hash Algorithms Known Issues PKI

RSASSA-PSS – Why Your Certificate Can’t Be Validated

A common theme has been arriving in my email box lately as well as many online forums. Consistently people are reporting error with certificates issued by their internal Microsoft ADCS based CAs. Problems range from Apple devices, Firefox, appliances and many other systems. When people examine their certificates they see that their certificates are SHA based, including many or all of their CAs in the hierarchy. So what is causing the problem?

PKCS #1 Version 2.1 was published as part of RFC 3447 in 2002 so it has been around for quite some time. Microsoft first implemented support for this in Server 2008 as part of the Crypto Next Generation revision for Windows. This standard defines an alternate and slightly improved method for CAs to sign certificates to eliminate some limited weaknesses. Despite its now 15 year availability, the VAST majority of systems and applications have failed/neglected/ignored the revision. As a result, certificates signed using this process are often unusable. However, the windows API (CAPI/CAPI2) and applications that rely on those API have support for the standard. Outside of that, you are likely to run into a wide range of support issues.

So how are these certificates getting signed with PKCS #1 V2.1 signatures? Microsoft defined the attribute  AlternateSignatureAlgorithm=1 in the CApolicy.inf file as the method to indicate to a CA that you want it to sign certificates created by that CA to be signed with PKCS #1 v2.1 – at least on standalone CAs such as Root and Policy CAs. It is important to note that references to DiscreteSignatureAlgorithm as the value name are incorrect. Sources such as the MS Press book and any other online sources are incorrect. During the beta release of Windows Server 2008, the value was called DiscreteSignatureAlgorithm. But with the full release and subsequent OS releases, using this value in your CAPolicy will result in no action as it is an unrecognized value.


Online Enterprise CAs have the ability to define this for end-entity certificates on a per-template basis. When a template is defined as a V3 or V4 schema version, the Cryptography tab will enable an option for the template administrator to enable use alternate signature format. An example template:


When a certificate has been signed with PKCS #1 v2.1 signatures, you will see the Signature Algorithm listed as RSASSA-PSS. You can refer to the Schemes section of the Wiki doc for PKCS #1 for more details. An example certificate:


In general, I recommend avoiding the use of PKCS #1 v2.1 signatures due to the diversity in most environments when it comes to support. To that end, the small increased security gain is greatly offset by support issues. If you have encountered this issue, you will need to determine how to remediate the signature compatibility. More often than not, people deploy this setting not realizing the support issues. If an application rejects an end-entity certificate due to the RSASSA-PSS encoding, then the certificate will need to be reissued. This can be turned off on the template that is being used to issue the certificate. There is also a VERY strong likelihood that if an application fails validation on end-entity certificates, it will fail the PKI chain if also signed with PKCS #1 v2.1. In this case, your CAs will need to modify their signature configuration in the registry and subordinate CAs reissued as needed. If the Root CA was signed this way, it too will need to be renewed. Start at the top of the chain and renew your chain downwards.

Read More
  • February 1, 2017

DCOM/RPC Hotfixes Issuance Policies Key Attestation Known Issues NDES OCSP PKI Server 2016 Smart Cards Trusted Platform Modules (TPM)

Windows Server 2016 – What’s New with ADCS

Well, here it is – the concise list of updates and changes to Active Directory Certificate Services (ADCS) for Windows Server 2016. I will go ahead and tell you now that there aren’t any new earth shattering features. Consider this an incremental set of improvements to ADCS. Remember that we still have things like Elliptical Curve Cryptography for us all to move to in the next few years as well – and that is already in the product.

So lets start with New Features:

  • Key Attestation now supports the use of Smart Card Key Storage Providers. Key Attestation is an assurance mechanism whereby a CA can ensure that a client has generated a keypair inside of a specific platform – historically that has been inside a Trusted Platform Module (TPM). This enabled organizations to deploy Virtual Smart Cards and ensure the keys were generated inside the TPM. Normally a CA has no enforcement or assurance of WHERE a key was generated for the enrollment request. In Windows Server 2016 this feature has been improved to support Smart Card KSP providers in addition to TPM providers.
  • Network Device Enrollment Service (NDES) now also supports Key Attestation enrollment enforcement as well. Previous to Windows Server 2016, Key Attestation only worked when directly enrolling with a CA (DCOM/RPC or CES/CEP).

Included Fixes/RollUps

  • Online Certificate Status Protocol (OCSP) now includes the hotfix changes from KB 2960124 to provide Deterministic responses to queries. This enables the OCSP server to respond with status of Revoked, Good, or Unknown. The OCSP server lacked the ability to respond with Unknown or an authoritative Good response without this hotfix in the past. Note, while the OCSP server includes the hotfix, the powershell script (or similar process) referenced in the KB article is still needed on your CA. Without this, the list of issued certificates will be unavailable to your OCSP server. The KB article has NOT been updated to reflect this as of this time.
  • OCSP includes hotfix KB 2923238 to enable the OCSP Responder to service requests that contain multiple certificates for revocation checking. This Hotfix is no longer applicable for Server 2016 since it is included.
  • As documented on my ADCS Hotfix Digest, Bug 5298357 – Bad ASN.1 encoding of certificate issuance policy extensions, has been fixed in Windows Server 2016 and is no longer an known problem. You can read more about this bug on the Server 2012 R2 portion of the ADCS Hotfix list.

As always, the list of hotfixes and known issues for ADCS is tracked on the digest at https://pkisolutions.com/adcs-hotfixes/. The Windows Server 2016 specific section is available at https://pkisolutions.com/2016hotfixes/.

Read More
  • December 2, 2016

Authentication Development Enrollment Internet of Things NDES NDES Policy Module PKI Policy Module White Papers

Creating a NDES Policy Module – A Programmers Guide

Microsoft introduced a great security improvement in Windows Server 2012 R2 to alter the standard Network Device Enrollment Service (NDES) security process. If you are familiar with the whitepaper I wrote for Microsoft (Securing and Hardening NDES) you’ll know I wrote about the disadvantages of using NDES for BYOD and Internet accessible enrollment solutions. The Microsoft InTune product team has been the only product so far to write a Policy Module that improves on the security and issuance model for NDES.

While Microsoft wrote the Policy Module capabilities with an open platform, to-date no other solutions have written a policy module. That is a real shame. Whether it’s a lack of information or visibility, I constantly work with my clients to make sure they are aware of how to secure NDES in their environments. If poorly deployed, it can present a significant thread gateway to your environment and a threat to your PKI.

Thankfully, Tochi Ezebube, an Engineer at Microsoft has written a paper on how to interface to, and write your own Policy Module. The paper is available here: https://msdnshared.blob.core.windows.net/media/2016/11/How-to-write-an-NDES-policy-module.pdf

While it is geared to developers, it goes a long way to bring light to the process and will certainly be a help to anyone looking to create an improved authentication mechanism for NDES.

Read More
  • November 30, 2016

Certificate Transparency PKI Qualified Subordination Revocation Watch Out

Certificate Transparency Enforcement and Microsoft CAs – Oct 2017 Deadline

ct_home_securityTo address some weaknesses in the public PKI trust process, Certificate Transparency (CT) was created to make it easier to detect and track fraudulent certificate issuance and use. The intent is that a small collection of log servers would contain information about valid certificates and browsers can check the log to see if a given certificate for a website is valid and hasn’t be misappropriated. To use CT, both Certification Authorities and Browsers need to be modified. Up to this point, CT has largely been a proof of concept and has had optional participation. As with anything, once one or more of the major browser providers begins enforcing activities (SHA2 anyone?), it will encourage other browsers to do like wise. From an administrative standpoint, if one of the major browsers will begin enforcing something, you might as well assume all of your web traffic will be impacted.

In this case, there is a huge potential impact on Microsoft ADCS Certification Authorities. It only applies to organizations that have contracted with a commercial provider to place part of their PKI under the commercial provider – this is often called Qualified Subordination. The benefit of this program is that anything the customer’s CA issues is fully trusted worldwide as if it came from that provider’s own CAs. There are extensive security and audit control requirements, but it can lower the cost of certificate acquisitions, provides globally trusted certificates and enables customers to use software and systems they are experienced with.

At the 39th meeting of the CA/Browser Forum (www.cabforum.org) the Chrome team announced plans which highlighted that publicly trusted SSL/TLS certificates issued after October 2017 would need to comply with Chrome’s Certificate Transparency policy in order to be trusted by Chrome.  On the 25th October Ryan Sleevi released additional details in this mail thread (https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/78N3SMcqUGw).  Please note that Mozilla is also considering to implement Certificate Transparency within the Firefox browser and although no dates have been given.

The impact is that as of this moment, Microsoft does not have a solution for ADCS Certification Authorities needing to comply with CT. This could potentially be implemented through a software change, exit module or 3rd party solution.

I have started a dialog with the ADCS Product Manager at Microsoft to provide details of customer impacts and possible options for resolution.

I have also started collecting details about affected organizations to provide a scale and scope of impact to Microsoft. Microsoft’s ability to address this issue will largely be driven by feedback and comments from the community. If you are using ADCS as a Qualified Subordinate, I would encourage you to reach out to me so I can add your details to the list of customers impacted by this enforcement.

Without a process change with ADCS, environments will be forced to either moved to a managed PKI solution by their commercial providers, move to a 3rd party solution such as EJBCA or eliminate their subordination program. Fortunately we have 11 months to address the issue and seek a workable solution – so please spread the word early.

Read More
  • November 29, 2016

Certificate Requests Certreq CES/CEP Enrollment PKI Web Enrollment

Submitting Netscape SPKI (SPKAC) Cert Requests to ADCS

Recently I was contacted on Twitter with a question about Microsoft’s support of Signed Public Key and Challenge (Netscape SPKI) for certificate enrollment requests. I have long taught in my classes that there are a number of formats supported by ADCS for certificate requests. So I consulted one of the tables I talk about in my In-Depth PKI class. Here you can see that clearly the Netscape Keygen/SPKAC/SPKI is supported, but this person was reporting an error every time they submitted a request.


The errors were usually “wrong user password” or “error parsing request“. So we checked out all the usual items by reviewing the CSR itself – all looked fine. We ensured the request was being submitted by a valid user with the appropriate permissions on the template and the CA. All looked good. When we switched to another format the request went through just fine. The SPKAC is an older format and frankly there isn’t much documentation on it, but it is clearly “supported”. I even found a MSDN noted that it was a supported format for Certificate Enrollment Protocol.

So I reviewed the SPKAC format a little further and found that one key difference of this format is that in the SPKAC format there is a “challenge” phrase that is embedded into the CSR. This challenge is verified by the CA to ensure the CSR is unaltered, which is a bit redundant since the request is already signed. If you dump a SPKAC request, you will see that there is an encoded ChallengeString, for example:


ChallengeString: “E425252E9E8C6166642D1CC6586605A5817BED57”

0000  30 82 01 50 30 82 01 22  30 0d 06 09 2a 86 48 86   0..P0..”0…*.H.

0010  f7 0d 01 01 01 05 00 03  82 01 0f 00 30 82 01 0a   …………0…

0020  02 82 01 01 00 99 e8 95  ae 94 cc 5f 89 91 38 31   ……….._..81

0030  95 54 76 06 72 93 46 6e  28 c9 86 8c f2 0e 5c a8   .Tv.r.Fn(…..\.

0040  80 c2 4b 35 d0 2a 10 d0  5a 16 f6 97 81 46 55 dd   ..K5.*..Z….FU.

0050  6a 30 92 d1 5d e8 6f c0  7c 96 5c 65 d0 b1 91 2e   j0..].o.|.\e….

0060  6a 50 ba 0e 05 71 43 d2  bb d0 e7 ee 90 f1 64 f4   jP…qC…….d.

0070  c4 05 d4 ba 19 13 a0 56  cd 99 57 a5 56 80 3a 83   …….V..W.V.:.

0080  ec d9 5c 77 79 9a 6a 36  34 63 5d d3 dd 35 cc f3   ..\wy.j64c]..5..

0090  f5 0c e2 d2 e1 dc 63 0c  77 f3 a0 ad e4 12 ee f5   ……c.w…….

00a0  f1 ef f1 25 26 7b 52 8f  54 2c 8c 01 03 e2 ca f8   …%&{R.T,……

00b0  9a cb bc 1c 51 32 2e 75  20 20 32 74 27 ee 20 5f   ….Q2.u  2t’. _

00c0  00 c9 59 66 88 14 6f e0  97 ec 7f 18 ec 2c 8c e3   ..Yf..o……,..

00d0  10 e6 d7 3e 4c b2 6d 8a  09 c8 ff 6c b6 85 1c b0   …>L.m….l….

00e0  3c 27 fd 92 6f bc 5e 62  a5 b6 72 50 a9 21 da 30   <‘..o.^b..rP.!.0

00f0  1b fb 08 f7 5b d3 e2 aa  88 81 81 04 57 9e 89 88   ….[…….W…

0100  b3 f7 10 e2 1d 54 63 d4  ae ee 9d 30 37 fe 41 9f   …..Tc….07.A.

0110  b5 56 fd 0f 73 75 6b c4  6d d1 da 71 94 50 c5 f7   .V..suk.m..q.P..

0120  0d 0f 1c ce 8b 02 03 01  00 01 16 28 45 34 32 35   ………..(E425

0130  32 35 32 45 39 45 38 43  36 31 36 36 36 34 32 44   252E9E8C6166642D

0140  31 43 43 36 35 38 36 36  30 35 41 35 38 31 37 42   1CC6586605A5817B

0150  45 44 35 37                                        ED57


So I reached out and did some research. It turns out that Microsoft hasn’t had SPKAC in it’s test suite for many years now and frankly it was unknown if it was even supported. But assuming it was still working, I needed to find the key to the submission process to get it to work. It turns out this format requires a very carefully crafted set of submission parameters to specify the challenge phrase.

Option #1

If the request contains no SPKAC challenge phrase, the certificate request will be accepted and processed normally.

Option #2

If the request contains a challenge, then the caller must submit the request with a matching challenge string included in the separate name-value pair strings passed to ICertRequest::Submit. This parameter string is formatted as follows: “name1:value1\nname2:value2”, where \n is a newline character that separates multiple name-value pairs. In this case: “Challenge:<ChallengeStringMatchingTheRequest>”. The challenge is compared as a case sensitive string. The web pages and certreq -submit are capable of adding request attribute name-value pair strings when submitting requests to the CA.

Once this was figured out, the SPKAC request, challenge phrase included, was successfully submitted to the CA and issued without any further problems. Since this is not documented anywhere else in Microsoft materials or on the web, this might be the only place where this is documented at all. Hopefully this will help anyone in the future faced with working with and processing SPKAC requests.

Read More
  • November 11, 2016

Appliances Hardware Security Modules PKI

Palo Alto and Bluecoat SSL Appliances and your PKI Security

Over the last year a common question has surfaced repeatedly as customers look to adopt SSL Packet inspection services for outgoing connections. These appliances are designed to allow monitoring and management of data contained inside of normally protected SSL sessions being initiated inside the organization. In order for these appliances to work, they have to be able to establish essentially a Man-In-The-Middle attack against corporate traffic to be able to inspect and manage that traffic.



Except in this case, the “Attacker” is a corporate security appliance, but the concepts are the same. To accomplish this MITM attack, these appliances (Palo Alto and Bluecoat are the most common) take advantage of a weakness in SSL/TLS. When a web browser negotiates an SSL/TLS session with a website, it doesn’t know WHICH CA should/did issue the certificate for the website – it only cares that it comes from a trust CA. Whether that is a commercial provider like Comodo, Globalsign or your internal PKI, it all doesn’t matter to the SSL/TLS negotiation.

So these appliances act as a subordinate CA of your PKI and use that certificate to create website certificates on the fly. Open a browser and go to www.contosobank.com, and the traffic is directed to the appliance and it creates a certificate for www.contosobank.com which subsequently chains to your PKI and is trusted. On the back-end, the appliance sets up a real connection to contosobank.com and sends your traffic on once it has been inspected/managed. So you are none the wiser.

So why do I bring this up? One of the issues with these appliances is that in order for them to function, they have to be a trusted CA. This can either take place as a self-signed certificate the appliance creates which you then need to distribute. This is a bad idea as it can’t be managed, revoked or monitored. It also doesn’t work well for machines you can push a Group Policy to as you would need to touch every device to trust this self-signed certificate. Another method is to enroll the appliance for a Subordinate CA certificate from your PKI.

The security of these Subordinate CA certificates should begin to tickle the hair on the back of your neck. These certificates (and keys) will be trusted by your enterprise, clients and servers like any other CA you have deployed. So what if you are using Hardware Security Modules (Thales/SafeNet Gemalto) to protect your CA keys? The act of enrolling and issuing Subordinate CA certificates to these devices could potentially nullify all of your HSMs and security controls you have put into place. If these appliances are the weakest link in your PKI, then you need to be sure you are adequately taking precautions to safeguard these devices to the same security level as your CA and the rest of the signing PKI infrastructure (OCSP, NDES, etc…)

So what can you do? Here are a few options to consider before blindly enrolling and deploying these devices:

  • Ensure the appliances can use HSMs to create and manage their keys. Bluecoat and Palo Alto both support HSMs by Thales and SafeNet. But you must make sure there is network connectivity to your HSMs and ensure the creation and enrollment of those keys are indeed occurring on the HSM. You will have no visibility of the protection of these keys when you view a certificate request sent to you. Be sure you are part of the creation process to ensure those keys are protected.
  • Use a Policy CA and place policy restrictions on the appliance. You can use a Policy CA to enforce the fact that the subordinate CA (the appliance) can only be trusted for Server Authentication. This will give it the ability to create the SSL/TLS certificates it needs, but will prevent anyone that can compromise the appliance keys from creating other types of certificates in your environment.
  • Place a Basic Constraint restriction in your environment that will make your existing 2 or 3 tier PKI that maximum number of tiers in the PKI. This will require the appliance to get it’s certificate from a higher CA in the chain. This will add more complexity to the enrollment and renewal process, but will remove the ability for anyone to easily get a subordinate CA certificate. It can also be done in a way that the appliance winds up as the bottom of the tier depth of the Basic Constraint as well – further limiting the exposure of the CA certificate on the appliance.



Read More
  • October 27, 2016

Training Classes

2017 PKI Training Schedule Now Live – Register Today!

It’s here, the 2017 PKI Training schedule is now live and accepting registrations. There are three In-Depth classes and two Advanced PKI classes split between the US and Europe. Be sure to check out the schedule and register early as classes usually sellout in advance.

San Jose CA (Feb 7-9) – Introduction to PKI, Certificates and Keys
Washington DC (March 6-10) – PKI In-Depth
Washington DC (May 8-12) – Advanced PKI
Frankfurt Germany (June 12-16) – PKI In-Depth
Portland Oregon (August 14 – 18) – PKI In-Depth
London, England (November 13-17) – Advanced PKI

As always, contact me if you have any questions. Registrations are available on the website here.

Read More
  • October 6, 2016

Architecture Maintenance Offline CA

Offline CA Maintenance – What Do You Really Need to Do?

In a previous post, I discussed the configuration and isolation of true offline Certificate Authorities. There I made reference to the fact that an offline CA is one that never sees the light of day, figuratively that is. The CA should be air-gaped from the network, which requires physical access to the CA to manage and issue certificates for roles such as Policy CA or for issuing a Certificate Revocation List (CRL). But how exactly do you maintain and keep the CA up to date? What exactly should you patch and manage?

One of the additional values of having an air-gaped CA is the fact that it is not subject to the access, risks and exploits that could be floating on your network. Because of this, we can be extremely targeted with what we update the CA with. We can avoid Microsoft’s “Patch Tuesday”, since the majority of those updates and issues address concerns outside of our CA. That’s not to say there couldn’t be an update that is applicable, but the standard “test and deploy all updates” don’t play here. Which is a good thing as manually updating your CA with these updates on a regular basis could be an administrative burden.

So here are the items that I consistently recommend to my customers:


1. Windows Service Packs

Microsoft has a very clear delineation of support products and configurations and running an OS without the requisite Service Pack could result in limited support from Microsoft. Outside of support, Microsoft only provides “best of abilities” support, which means hotfixes and code changes are out of the question. So even though your CA is working just fine (today), you should ensure your updates/upgrades for your CA keep it in a supported state. More details at: https://support.microsoft.com/en-us/lifecycle


2. Certificate Services Specific Hotfixes

One of the challenges I often had while at Microsoft was recommending to customers that they ensure all of their ADCS roles were properly patched with any hotfixes. If you are running an ADCS role and there is a hotfix, you do not need to wait until the problem occurs before applying the hotfix. In fact, some hotfixes like the OCSP 2960124 enable Deterministic OCSP responses – something you wouldn’t notice unless you were aware of the hotfix or happened to use a network sniffer to capture and analyze the OCSP responses your server is sending out.

So while Microsoft does not have an official list of all the hotfixes available for ADCS, I do! You can find it here on the PKI Solutions website at https://pkisolutions.com/adcs-hotfixes. Find the appropriate OS for your ADCS roles and review the list. When new hotfixes are released I will update the list here for your reference.


3. Any Date/Time/Daylight Savings Time Updates

Occasionally there are changes to Daylight Savings times, or even patches to address issues with drifting time/date in some environments – anyone remember the early VMWare issues in this regard? The net affect means your offline CA could wind up with a different time than the rest of your PKI components. That means an ill-timed CRL publish could be off by more than an hour. A CA by default only accommodates a 10 minute time-skew. A hour or more could cause wide-spread certificate validation problems in your environment.


4. Anti-Virus

I know it seems on the surface to be counter-intuitive – “Why would I have anti-virus software on my offline CA”? Would you like to guess the only place I’ve ever been infected with a virus from a customer? It was an Offline CA, at a bank! How did this happen? If the Root CA is offline, how are files like the CRL copied off of the Root? That’s right, via a flash drive. At some point an administrator used a flash drive that had been infected and the virus laid in wait on the CA for my to insert my flash drive to get some configuration files. Along comes the virus and my laptop detects it. Luckily the virus didn’t destroy data or cause a larger problem. So I always recommend AV software for customers now, and IF you remember to update the signatures, great. But I’d rather make sure there is some AV software, even if the signatures are old. Something is better than nothing.


So now that we covered the What, now we can discuss the When. The easy answer is unless any of the above items is a critical issue that can cause a problem, all of these can wait for the next CA maintenance window. This generally occurs whenever the CA is powered on to perform the CRL publish process. So it’s a good time to build a flash drive and get all the items you need to update the CA brought over and applied at the same time.

So through having an isolated, offline CA, your maintenance demands are actually reduced. It just means you have to be diligent in tracking and applying these items on your own.

Read More
  • October 4, 2016

  © Copyright 2013-2016 PKI Solutions Inc. // All Rights Reserved // Terms of Service // Privacy Policy // Pricing and Refund Policies