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)
Continue reading „Die Beantragung eines Trusted Platform Module (TPM) geschützten Zertifikats schägt fehl mit Fehlermeldung „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.

Continue reading „Google Chrome und Microsoft Edge prüfen Sperrstatus von Zertifikaten nicht“

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.

Continue reading „Microsoft Outlook: Einsehen, welcher Algorithmus für eine S/MIME verschlüsselte oder signierte E-Mail verwendet wurde“

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.

Continue reading „Microsoft Outlook: Den verwendeten Verschlüsselungsalgorithmus für S/MIME steuern“

The "S/MIME Capabilities" certificate extension

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.

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

Continue reading „Die „S/MIME Capabilities“ Zertifikaterweiterung“

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

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.

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.

Continue reading „Die „S/MIME Capabilities“ Zertifikaterweiterung in ausgestellten Zertifikaten um die Cryptography Next Generation (CNG) Algorithmen erweitern“

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.

Continue reading „SSH (PuTTY) auf Windows mit einem Zertifikat / einer Smartcard verwenden“

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.

Continue reading „Verwenden von nicht definierten Relative Distinguished Names (RDN) in ausgestellten Zertifikaten“

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.

Continue reading „SSCEP für Linux (Debian Buster) installieren und Zertifikate über den Registrierungsdienst für Netzwerkgeräte (NDES) beantragen“

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.

Continue reading „Zertifikatbeantragung für Windows-Systeme über den Registrierungsdienst für Netzwerkgeräte (NDES) mit 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.
Continue reading „Details zum Ereignis mit ID 32 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“

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.
Continue reading „Details zum Ereignis mit ID 200 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“

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
Continue reading „Details zum Ereignis mit ID 21 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“

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

Event Source:Microsoft Windows Kerberos Key Distribution Center
Event ID:302 (0x12E)
Event log:Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational
Event type:Information
Event text (English):The Key Distribution Center (KDC) uses the below KDC certificate for smart card or certificate authentication. Kdc Certificate Information: Issuer Name: %1 Serial Number: %2 Thumbprint: %3 Template: %4
Event text (German):The Key Distribution Center (KDC) uses the following certificate for smart card or certificate authentication. KDC certificate information: Issuer name: %1 Serial number: %2 Fingerprint: %3 Template: %4
Continue reading „Details zum Ereignis mit ID 302 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“

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

Event Source:Microsoft Windows Kerberos Key Distribution Center
Event ID:19 (0x80000013)
Event log:System
Event type:Warning
Event text (English):This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate.
Event text (German):This event indicates that an attempt was made to use the smart card login, but the KDC cannot use the PKINIT protocol because a suitable certificate is missing.
Continue reading „Details zum Ereignis mit ID 19 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center“
en_USEnglish