Certificate usage - Page 14

Requesting a certificate is not possible because the certificate template is not displayed. The error message is "Can not find a valid CSP in the local machine."

Assume the following scenario:

A certificate is requested for a user or a computer from a certificate authority via the certificate management console (certlm.msc or certmgr.msc).
Autoenrollment does not request a certificate from the desired certificate template, although it is enabled and the permissions are set accordingly.
The desired certificate template is not displayed when applying manually via the Microsoft Management Console (MMC). If the "Show all templates" check box is selected, the following error message is displayed for the desired certificate template:

Cannot find object or property.
Can not find a valid CSP in the local machine.

Configure a certificate template to use the Microsoft Platform Crypto Provider to enable private key protection through a Trusted Platform Module (TPM).

Since Windows 8, it has been possible for private keys for certificates to be protected with a - if available - Trusted Platform Module (TPM). This ensures that the key is truly non-exportable.

The process for setting up a certificate template that uses a Trusted Platform module is described below.

Requesting a Trusted Platform Module (TPM) protected certificate fails with error message "The requested operation is not supported. 0x80090029 (-2146893783 NTE_NOT_SUPPORTED)"

Assume the following scenario:

A certificate template is configured to use the Microsoft Platform Crypto Provider, so the private key generated when the certificate is requested is protected with a Trusted Platform Module (TPM).
However, certificate request fails with the following error message:

An error occurred while enrolling for a certificate.
A certificate request could not be created.
Url: CA02.intra.adcslabor.de\ADCS Lab Issuing CA 1
Error: The requested operation is not supported. 0x80090029 (-2146893783 NTE_NOT_SUPPORTED)

Google Chrome and Microsoft Edge do not check certificate revocation state

More and more companies are using the Google Chrome browser or the new Chromium-based Microsoft Edge (codename Anaheim) on.

When distributing one of these two browsers, it should be noted that they sometimes behave differently from other browsers in terms of certificates.

Besides the fact that Chromium, unlike Internet Explorer and the previous Edge (codename Spartan) the RFC 2818 enforces, it also behaves in the Checking blocking information different.

Microsoft Outlook: View which algorithm was used for an S/MIME encrypted or signed email

Below is a description of where it is possible to view which symmetric algorithm was used to encrypt an email received, and which hash algorithm was used for a signed email.

Microsoft Outlook: Control the encryption algorithm used for S/MIME.

When S/MIME certificates are issued, they usually contain a certificate extension "S/MIME Capabilities". This certificate extension is specified in RFC 4262 and can be used by compatible e-mail programs to specify the symmetric algorithms supported by the recipient of an encrypted message. The sender should then choose the strongest algorithm supported by the recipient.

Microsoft Outlook uses (if available and required) the information in the "S/MIME Capabilities" extension of a certificate. Below is a description of how it is used and which algorithms are selected.

The "S/MIME Capabilities" certificate extension

Among other things, the Microsoft Outlook extension is evaluated and used to determine the symmetric algorithm for an encrypted email.

Extend the "S/MIME Capabilities" certificate extension in issued certificates to include the Cryptography Next Generation (CNG) algorithms.

However, if you take a look at the symmetric algorithms included in such a certificate, you will probably find that the list contains rather outdated algorithms - the "strongest" of these algorithms is Triple DES (3DES), which is now considered obsolete.

Use SSH (PuTTY) on Windows with a certificate / smart card

Secure administration of Linux systems includes avoiding SSH logins by password and instead logging in with RSA keys.

The de facto standard for SSH connections on Windows is PuTTY. Here, logon with RSA keys is implemented, but only key files can be used, which has the disadvantage that they are almost unprotected in the file system.

Surely a great option would be to use RSA keys from the Windows world, and perhaps even stored on a physical or virtual smartcard.

Use of undefined Relative Distinguished Names (RDN) in issued certificates

Sometimes it is necessary to allow Relative Distinguished Names (RDNs) in issued certificates that are not defined and accordingly not included in the SubjectTemplate value of the certification authority registration could be configured.

An example of this is the Organization Identifier with Object Identifier 2.5.4.97, which is required, for example, for certificates that are used for the eIDAS Regulation are compliant.

Install SSCEP for Linux (Debian Buster) and apply for certificates via the Network Device Enrollment Service (NDES).

If you want to equip a large quantity of systems with certificates, a Manual request and renewal of certificates is not an option. The only viable path is automation.

For systems that are not members of the Active Directory forest, an automatic certificate request via RPC/DCOM not an option.

For certain use cases, the Simple Certificate Enrollment Protocol (SCEP) is an interesting alternative. There are not only clients for Windows for this protocol, but also for Linux with SSCEP. SSCEP is used, among other things, by thin clients with the eLux operating system used.

The following describes how to set up the SSCEP client on a Debian Buster Linux system - either to use it to manage servers or to be able to test the client-side behavior.

Certificate Enrollment for Windows Systems via the Network Device Enrollment Service (NDES) with Windows PowerShell

If you want to equip Windows systems with certificates that do not have the option of communicating directly with an Active Directory-integrated certification authority, or that are not even in the same Active Directory forest, the only option in most cases is to install certificates manually.

Since Windows 8.1 / Windows Server 2012 R2, however, there is an integrated client for the Simple Certificate Enrollment Protocol (SCEP) on board. On the server side, SCEP is implemented via the Network Device Enrollment Service (NDES) implemented in the Microsoft PKI since Windows Server 2003.

A particularly interesting feature of SCEP is that the protocol allows a certificate to be renewed by specifying an existing one. So what could be more obvious than to use this interface? What is still missing is a corresponding automation via Windows PowerShell.

Details of the event with ID 32 of the source Microsoft-Windows-Kerberos-Key-Distribution-Center

Event Source:	Microsoft Windows Kerberos Key Distribution Center
Event ID:	32 (0x80000020)
Event log:	System
Event type:	Warning
Event text (English):	The Key Distribution Center (KDC) uses a certificate without KDC Extended Key Usage (EKU) which can result in authentication failures for device certificate logon and smart card logon from non-domain-joined devices. Enrollment of a KDC certificate with KDC EKU (Kerberos Authentication template) is required to remove this warning.
Event text (German):	The Key Distribution Center (KDC) uses a certificate without Extended Key Usage (EKU) for the KDC. This can lead to authentication errors during device certificate enrollments and smart card enrollments of devices without domain affiliation. Enrollment of a KDC certificate with KDC EKU (Kerberos authentication template) is required to eliminate this warning.

Details of the event with ID 200 of the source Microsoft-Windows-Kerberos-Key-Distribution-Center

Event Source:	Microsoft Windows Kerberos Key Distribution Center
Event ID:	200 (0xC8)
Event log:	Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational
Event type:	Warning
Event text (English):	The Key Distribution Center (KDC) cannot find a suitable certificate to use. This KDC is not enabled for smart card or certificate authentication.
Event text (German):	The Key Distribution Center (KDC) cannot find a suitable certificate. This KDC is not enabled for smart card or certificate authentication.

Details of the event with ID 21 of the source Microsoft-Windows-Kerberos-Key-Distribution-Center

Event Source:	Microsoft Windows Kerberos Key Distribution Center
Event ID:	21 (0x80000015)
Event log:	System
Event type:	Warning
Event text (English):	The client certificate for the user %1\%2 is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was : %3
Event text (German):	The client certificate for user %1\%2 is not valid. The result was an error during smartcard login. Contact the user for more information about the certificate to be used for the smartcard application. Chain status: %3