+1 971 231 5523 info@pkisolutions.com

The PKI Guy Blog

PKI Solutions Inc. The PKI Guy Blog


Book Recommendation – Hacking the Hacker (Roger Grimes)

A good friend of mine I met while at Microsoft just had one of his books released. Roger is a Security Columnist for InfoWorld and is a pretty dang sharp guy. His new book, Hacking the Hacker has some good information in many different areas confronting modern cybersecurity specialists. Of particular interest to anyone reading this blog is his inclusion of information around cryptography, hashes and profiles Mark Hellman, of Diffie Hellman fame. If you are looking at expanding your toolset and knowledge, this is a great book to do that.

Hacking the Hackers (https://www.amazon.com/Hacking-Hacker-Learn-Experts-Hackers/dp/1119396212/), a new book by Roger A. Grimes, promotes the computer security field as a good career for smart people to pursue by profiling 26 industry luminaries, experts, and educators (including me). Each profile is prefaced by a chapter on the relevant technology and how to defend against malicious hackers. It ends with two chapters designed to help parents guide their children into careers in ethical hacking. Hacking the Hacker was picked by (ISC)2 as their first non-exam book recommendation.


Read More
  • June 5, 2017

Training Classes

PKI Solutions Announces Training Scholarships for PDX Cyber Camp 2017

I am pleased to announce that in partnership with the PDX Cyber Camp, PKI Solutions has created a scholarship for 3 young students attending the PDX Cyber Camp to attend one of my PKI In-Depth training classes this year. This will be a great way to offer these students an exposure to PKI and all of it’s uses. The students will build off of their knowledged learned in the camp and get a chance to network with cybersecurity professionals from around the world.

The original Press Release is available on PRWeb here.


The PDX Cyber Camp, a non-profit cybersecurity education program for high school students sponsored by Pacific Star Communications Inc. (PacStar), announced today that PKI Solutions Inc. will award $15,000 in scholarships for in-depth Public Key Infrastructure (PKI) training to three students from this year’s cyber security summer camp. PDX Cyber Camp 2017, to be held during the week of July 17 to July 21, is designed to give students hands-on, introductory experience to cybersecurity principles and policies. These new scholarships, valued at $5,000 each, will pay for three motivated students to attend an intensive, week-long PKI training course later in the summer so they can continue their cybersecurity education with additional hands-on training provided by a leading expert in this field.

“A strong understanding of PKI methodologies and best practices is an important part of a well-rounded cybersecurity training program, so we’re excited to have one of the leading PKI experts provide in-depth training to three deserving PDX Cyber Camp 2017 students,” said Charlie Kawasaki, chief technology officer of PacStar and co-founder and organizer of the PDX Cyber Camp. “There’s a reason why the founder of PKI Solutions is known as ‘The PKI Guy.’ His years of experience working with Microsoft and deep PKI expertise have made his classes extremely popular with information technology and security specialists around the world.”

According to Kawasaki, the PKI scholarships will be awarded at the conclusion of the PDX Cyber Camp 2017 in July. The scholarships to PKI Solution’s Microsoft PKI In-Depth Training course, to be held August 14 to August 18 in Portland, Oregon, will be awarded to two student organizers of the PDX Cyber Camp in recognition of their leadership and one camp attendee who will be selected based on her/his outstanding performance during the cybersecurity camp.

“We are very pleased to offer these scholarships for in-depth PKI training to these motivated students so they can learn more about the intricacies of maintaining computer system security,” said Mark B. Cooper, founder of PKI Solutions. “I remember my own interest in technology was sparked during high school and I’m looking forward to the opportunity to help these eager, young students pursue careers in cybersecurity. There is a large and growing need for more experts in this rewarding field.”

Students who participate in the Microsoft PKI In-Depth Training course will receive deep-dive training on PKI and Certificate Services focused on building knowledge and skills. The course has a strong emphasis on security, best practices, and hands-on skills labs. Upon completion of the course, students will receive certificates of completion and the opportunity to network with cybersecurity professionals from around the world who are also attending the course. Students who participate in the PDX Cyber Camp will also receive valuable experience that can help them qualify for cybersecurity internships. In fact, three students from the 2016 camp secured internships at local cyber and network security companies last year.

PDX Cyber Camp 2017 Details

  •     Date: Monday, July 17 through Friday, July 21, 2017
  •     Times: Monday to Thursday 9:00 a.m. to 4:00 p.m., Friday 9 a.m. to 1p.m.
  •     Locations:

o    Location #1(Girls Only): Lincoln High School, 1600 SW Salmon St, Portland, Oregon
o    Location #2 (Co-Ed): Center for Advanced Learning, 1484 NW Civic Dr., Gresham, Oregon
o    Location #3 (Co-Ed): Mentor Graphics, 8005 Boeckman Rd, Wilsonville, Oregon – This location is FULL (additional applications will be wait listed)

  •     Cost: $150 per session. Scholarships available based on financial need.
  •     Food: Lunches provided.
  •     Each camp facility supports a maximum of 25 students to ensure that each student will have a dedicated computer system.

How to Apply
Interested students may apply here http://www.softwarediligence.com/pdxcybercamp/. The deadline for applications is Thursday, June 1, 2017, although early application is encouraged. Students do not need to have experience or prior training in cybersecurity. Prerequisites include a demonstrated interest in computers or a strong recommendation from a teacher. The selection criteria will also consider gender, ethnic and socio-economic factors to promote diversity and inclusion of under-represented groups in the STEM and cybersecurity fields.

In addition to the PDX Cyber Camp 2017 title sponsor, PacStar, other sponsors include IBM, McAfee by Intel Security, Mentor Graphics, Galois, Absolute Software, Cylance, Hueya, New Relic, McKenzie Worldwide, Software Diligence Services, and the Technology Association of Oregon.

PKI Solutions provides consulting, training and best practices assessments for Microsoft Certificate Services-based Public Key Infrastructure (PKI) to companies and security professionals focused on enterprise security. Visit https://www.pkisolutions.com for more information.

For more information about the PDX Cyber Camp, please visit: http://www.softwarediligence.com/pdxcybercamp/.


Read More
  • May 3, 2017

Certificate Templates Documentation Hall of Shame PKI

Help a SME Out – Don’t Guess at Template Settings

One of the areas we spend time on in the PKI In-Depth class is learning about Certificate Templates. There are a lot of tabs in the template manager and a lot of specific settings on those tabs. I can certainly understand the desire to click those pretty checkboxes, toggle radio buttons and get lost in the beauty of a Win32-based GUI form. But this can lead to many issues down the road. We literally spend almost half a day in class going over each and everyone of these options and settings in the template.

But my focus today is on the prevalence of bad tech articles that include bad or worse, incorrect information on using certificate templates. Today’s example is a lovely article from VMWare on creating a template for use with vSphere 6.0 here.

This article is well meaning, intending to help you create a template so that vSphere can use the proper type of certificate. But there are a number of bad things lurking in this article. Some are more nefarious than others, but I’d rather the details be right.

So let’s review what is wrong in the article:


One of the things this article does not cover at all is the security ramification of implementing this solution. This article has you creating subordinate CA templates for use with the product. If you are at all concerned about security in your PKI you should be aware that assigning any application or device a Subordinate CA certificate delegates that device to act just like any other CA in your environment. That means whatever is creates (or is covertly tricked into creating) will be trusted throughout your environment. If you are using Hardware Security Modules for your CAs, when you set up this appliance, how will its key be protected? That key is just as sensative as the key being used by your “standard” CA.



The first issue you will see in the article is actually an aside that they repeat several times in the article

Note: If you have an encryption level higher than SHA1, select Windows Server 2008 Enterprise.

What’s wrong with this? Well, a few things frankly:

  1. SHA is a hashing algorithm intended for message integrity and source verification. It does not encrypt anything.
  2. The version/compatibility of the template has no bearing on the hash that will be used when the certificate is signed by the CA. If the CA is configured to sign certificates with SHA256, that will occur regardless of the template version. PERHAPS they were referring to another misperception that by using a Server 2008 template (V3+) that you can choose to use a Key Storage Provider and as a result you can choose to sign your certificate REQUEST with SHA256, but this only affect the request file being sent to the CA as outlined in this article I wrote. But I seriously doubt that was the case.



Another area that the article glosses over are these two steps:

Select Server Authentication and click Remove, then OK.
Note: If Client Authentication exists, remove this from Application Policies as well.

The template you are working with ONLY has Server and Client Authentication to begin with. By removing those two EKUs you are left with no defined EKUs. This means ALL Key Usages are allowed.


NonRepudiation for SSL?

Nonrepudiation is a concept of using specific identities to be able to determine that a specific individual was the only one that could have used that identity for a specific task. With an appropriate set of process and controls, the owner of that identity should not be able to challenge the authenticity of their actions. So what does this requirement have to do with VMWare and SSL needs? Excellent question? Why is this step being used?

Select Key Usage and click Edit
Select the Signature is proof of origin (nonrepudiation) option. Leave all other options as default.


Publish Certificate in AD

This one is a common mistake – but no excuse. Checking this box results in no visible change so the user/engineer never really knows what they did was unneeded. In some cases this can cause massive AD replication issues.

  1. Ensure Publish certificate in Active Directory is selected.

This option is used for Secure Email and Encrypted File System certificate templates so that the CA will publish a copy of the user’s encryption certificate to AD when the certificate is issued. This is needed so that Secure Email can locate a recipients public key to be able to encrypt a message to that user. EFS can also be used to allow other users to decrypt a file, and to do that, EFS needs to be able to locate the other users public key so the EFS File Encryption Key (FEK) can be protected with that users public key. Publishing any other certificate to AD just serves to bloat AD with unnecessary items that have to be replicated.



So there you go – one example of an authoritative technical document designed by someone who knows their OWN product but has made a lot of assumptions about certificates and templates to “get it to work”. While I don’t hold anyone specifically responsible, the implementer who is going to find this article is unlikely to question the items as much as they should. So everyone owes it to themselves, the security community and their customers to make sure they are recommending GOOD practices and not quick fixes.

Also, this marks the beginning of the “Documentation Hall of Shame” series as selectable by the blog category aptly named “Documentation Hall of Shame“. Stay tuned for future additions and if you come across suspicious documentation for PKI, send it over along with a pointer to what looks fishy to you.

Read More
  • May 2, 2017

Certificate Validation Certutil Documentation Hall of Shame 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

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