Schedule a Demo
Thanks for this. Its a good consideration/reflection for selecting crypto method. When setting up a 2 tier pki, I was following MS best practices, but when I first noticed CAPolicy.inf incorrect syntax, conflicting info, and they were still mentioning CRLDistributionPoint URL as https I quickly realized I need to look for other sources.
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?
Expand Your PKI Visibility
Discover why seeing is securing with revolutionary PKI monitoring and alerting.
Learn More About PKI Spotlight®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.
Related Resources
Mark B. Cooper
President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.
View All Posts by Mark B. CooperComments
-
-
Thanks for the positive feedback – I’m glad to hear the information has been useful. There is certainly a variety of information out there, many of which are less than accurate.
-
-
Very useful! I have spent the past three hours pouring over RFC’s trying to figure out what the correct signing algorithm would be for a new PKI. NIST recommends but does not require RSASSA-PSS they sort of nudge the opinion in that direction but it is never made mandatory. Compatibility is a major driver in the real world. Do you have and information or sources of information on compatibility beyond the world of Windows?
-
A comprehensive list would be great! However, it just doesn’t exist. Given the marginal security benefit from PKCS #1 v2.1 signatures (RSASSA-PSS) it just isn’t something we commonly recommend for deployment. In well defined environments such as IoT where it is a closed ecosystem it is much easier. Since NIST and others don’t see it as a requirement either I doubt we will see the landscape change until it is a mandatory item. It’s been release for 17 years and still hasn’t been found to be common place yet.
-
-
Is there any other way to tell if a certificate is PKCS #1 V2.1 format? My root CA certificate has the value “sha512ECSA” for Signature Algorithm instead.
-
Luke, in your case you are not using PKCS #1 v2.1 signatures. However your root is using Elliptical Curve which could cause problems in another way. Most modern OSes and systems are capable of using ECC, but there could be compatibility issues across a typical enterprise. As a result we don’t generally see ECC in use except for close ecosystems with a very small, defined type of platform or OS. Typically things like IoT where we know all of the systems participating in the ecosystem and know their capabilities.
-
-
Very helpful. Thank you.
Would you please give some insight to https://www.rfc-editor.org/rfc/rfc8446? It says, “Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3) MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. “-
RSASSA-PSS is definitely a more, modern signature process. The question is ultimately client-side support for any communication that is going to enforce it. In the case of TLS, that means the browsers will need to support RSASSA-PSS. Luckily most systems do not rely on the underlying OS, which may or may not support RSASSA-PSS, to perform verifications like this. However, some still do!
-