November 2020 - Uwe Gradenegger

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.

When installing an Active Directory integrated certificate authority, the error message "Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)" appears.

Assume the following scenario:

A certification authority (Enterprise Certification Authority) integrated into Active Directory is installed via Windows PowerShell.
Delegated permissions are used to install the certificate authority. Thus, the installing user is not a member of the Enterprise Administrators group.
After running the Role Configuration Wizard, one or more of the following error messages is displayed on the command line:

Setup could not add the Certification Authority's computer account to the Pre-Windows 2000 Compatible Access security group. Certificate managers Restrictions feature will not work correctly on this Certification Authority. To fix this, an administrator must manually add the Certification's Authority's computer account to the Pre-Windows 2000 Compatible Access security group in Active Directory. Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Warning: Setup could not add the certification authority's computer account to the cert Publishers Security Group. This Certification Authority will not be able to publish certificates in Active Directory. To fix this, an administrator must manually add the Certification Authority's computer account to the Cert Publishers security group in Active Directory.  Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Installation of a certificate authority certificate fails with error message "Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)".

Assume the following scenario:

A certification authority (Enterprise Certification Authority) integrated into Active Directory is installed.
Delegated permissions are used to install the certificate authority. Thus, the installing user is not a member of the Enterprise Administrators group.
After the certification authority certificate is issued by the parent certification authority, it is installed to complete the role configuration.
The installation of the certificate authority certificate fails with the following error message:

Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

The installation of a certificate authority certificate fails with error code "NTE_PROVIDER_DLL_FAIL".

Assume the following scenario:

A certification authority is installed.
The certificate authority uses a Gemalto/SafeNet Hardware Security Module (HSM) with the SafeNet Luna Key Storage Provider.
After the certification authority certificate is issued by the parent certification authority, it is installed to complete the role configuration.
The installation of the certificate authority certificate fails with the following error message:

An error was detected while configuring Active Directory Certificate Services.
The Active Directory Certificate Services Setup Wizard will need to be rerun to complete the configuration.
The new certificate public key does not match the current outstanding request.
The wrong request may have been used to generate the new certificate: Provider DLL failed to initialize correctly.
0x8009001d (-2146893795 NTE_PROVIDER_DLL_FAIL)

SSCEP: Subject of our request does not match that of the returned Certificate!

Assume the following scenario:

A certificate request is made on a Linux system (for example, a thin client) by means of a SSCEP against a Network Device Enrollment Service (NDES) performed.
The certificate request fails with the following error message:

sscep: Subject of our request does not match that of the returned Certificate!

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.

Change the order of the Relative Distinguished Names (RDNs) in the subject of issued certificates.

The Microsoft Certification Authority accepts subjects from certificate requests for templates in which their specification by the requester is allowed, not 1:1 in the issued certificate.

Instead, both is defined, which Relative Distinguished Names (RDNs) are allowedas well as in which order they are written to issued certificates. However, this order can be changed. How this is done is explained below.

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.

Regular password change when configuring the Network Device Enrollment Service (NDES) with a static password.

Suppose you are running a Network Device Enrollment Service (NDES), which relies on is configured to use a static password. In this case, unlike the default configuration, the password for the Requesting certificates via NDES clients never.

However, one may aim for an intermediate way, for example, a daily change of the password. The following describes a way to automate the change of the password.

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.

Network Device Enrollment Service (NDES) Basics

The Simple Certificate Enrollment Protocol (SCEP) was developed by Verisign for Cisco in the early 2000s to provide a simplified method for requesting certificates. Previously, network devices required manually generating a certificate request on each device, submitting it to a certificate authority, and then manually reinstalling the issued certificate on the corresponding device.

Description of the different certificate formats

X.509 certificates are always encoded in the Distinguished Encoding Rules (DER) format. This is a binary, machine-readable format.

DER-encoded certificates can, however, also be converted into a text-based format using the BASE64 process so that they can be transmitted in an e-mail body, for example. BASE64 encloses the DER-encoded format, i.e. the certificate is and remains DER-encoded in any case.

Authentication at the Network Device Enrollment Service (NDES) with an existing certificate (renewal mode)

The Network Device Enrollment Service (NDES) has the ability to authenticate with a previously issued certificate in order to reapply for a certificate with the same content. This is very convenient for renewal operations, as it eliminates the need to apply for a one-time password beforehand.