NitroKeyHSM2, OpenSC and Microsoft CA - no SHA512

mmfin · January 30, 2025, 6:22pm

Trying to create a new standalone CA, leveraging the NitroKey with an RSA4096 stored on the HSM2 itself, and then using it to generate a SHA512 cert to deploy the root CA using Windows Server 2025. However, I cannot seem to find a way to have additional options beyond the SHA1, md2, md4 or md5 available.

How do I get SHA512 visible in the Microsoft CA, connecting to the nitrokey HSM via OpenSC when deploying a new standalone root CA, and have the CA configuration wizard leverage the keypair on the HSM2 to proceed with the deployment using SHA512? I’ve installed both the 32 and 64 bit versions of OpenSC (latest version 0.26.1) on the server. Am I missing drivers? or some .conf or .ini configuration which points to a dll somewhere I might have missed?

any suggestions and ideas would be appreciated.

edited for additional clarity.

mmfin · February 10, 2025, 7:09pm

nothing from anyone? the NitrokeyHSM2 is perfect, but I just can’t get the Windows Certificate Authority to see any cryptography higher than SHA1, md2, md4 or md5, to generate a cert for a standalone root CA deployment based on the 4096 RSA key I had the HSM generate internally.

I scoured the documentation, Git forums, OpenSC wiki/bugs, and followed those respective tangents, but still no viable solution.

surely i’m not the first person who has attempted this?

daringer · February 11, 2025, 11:04am

hey,

generally the HSM2 should have far more mechanisms available apart from sha1, see pkcs11-tool -M outputs:

❯ pkcs11-tool -M
Using slot 0 with a present token (0x0)
Supported mechanisms:
  SHA-1, digest
  SHA224, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDSA-SHA1, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDSA-SHA224, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDSA-SHA256, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDSA-SHA384, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDSA-SHA512, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDH1-COFACTOR-DERIVE, keySize={192,521}, hw, derive, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDH1-DERIVE, keySize={192,521}, hw, derive, EC F_P, EC parameters, EC OID, EC uncompressed
  ECDSA-KEY-PAIR-GEN, keySize={192,521}, hw, generate_key_pair, EC F_P, EC parameters, EC OID, EC uncompressed
  RSA-X-509, keySize={1024,4096}, hw, decrypt, sign, verify
  RSA-PKCS, keySize={1024,4096}, hw, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,4096}, sign, verify
  SHA256-RSA-PKCS, keySize={1024,4096}, sign, verify
  SHA384-RSA-PKCS, keySize={1024,4096}, sign, verify
  SHA512-RSA-PKCS, keySize={1024,4096}, sign, verify
  RSA-PKCS-PSS, keySize={1024,4096}, hw, sign, verify
  SHA1-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
  SHA256-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
  SHA384-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
  SHA512-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
  RSA-PKCS-OAEP, keySize={1024,4096}, hw, decrypt
  RSA-PKCS-KEY-PAIR-GEN, keySize={1024,4096}, hw, generate_key_pair

So my assumption would be (w/o having any experience with a Windows CA) that the tooling is responsible to use any of those. In order to help, you might also want to share more specifics or even the exact commands so somebody else can reproduce your issue.

best

Nobrac · February 11, 2025, 11:28am

Hey there.

I have exactly the same problem as you and have already tried several things and read through what feels like all the Github posts, unfortunately I’m also getting nowhere and I’m slowly running out of things to try.

To reproduce:

Install blank Windows Server 2025 (already tried it with 2022, 2019 too)
Install the Certificate Authority role through Server Manager

image746×550 62.3 KB
During setup, select create new private key

image749×545 94.7 KB
Select “OpenSC CSP” as cryptographic provider

It would be cool to find a way to support this correctly. I work at an MSP and a lot of customers would want to use this feature.

I’ve also installed both the 32 and 64 bit versions of OpenSC (latest version 0.26.1).

I think the Windows CA does not natively support PKCS11, but maybe there is a way around this?

mmfin · February 12, 2025, 3:24pm

Nobrac has demonstrated the exact issue we’re experiencing. any additional suggestions?

I’ve tried adjusting the opensc.conf to prevent caching and have added the regkeys for the nitrokeys into the registry of the Server 2025. I’ve playing with the opensc pcks11 on a debian 12 linux box and can see all those options, but even using the pcks11 wrapper from opensc on server 2025 also shows me all the cryptography options. The problem is when the Microsoft CA wizard calls OpenSC, I only see the same options in nobrac’s post. I’ve also, using the pcks11 wrapper to generate an x509 cert on the NitroKeyHSM2, and within the wizard selecting “use an existing private key” and selecting the OpenSC, I can see a serial number, but i cannot import them either as i cannot get cryptography higher than SHA1.

my questions, is Windows leveraging a wrong driver? is there a “better” .dll which I should be using rather than the defaults for the WindowsCA wizard, when calling openSC, generate the cert on the USB. I’m not interested in compiling my own for this, but it would be fantastic for my use case, and also for the usecase that Nobrac has.

saper · February 12, 2025, 6:07pm

I think that you have already correctly figured out that this might be a problem with OpenSC CSP minidriver that is tracked at

github.com/OpenSC/OpenSC

Unable to use OpenSC for root certificate in ADCS (certificate services aka the PKI)

opened 11:21AM - 30 Dec 20 UTC

vletoux

### Problem Description When setup ADCS, you can choose to use a smart card a…s a root CA. Choose Enterprise & Root CA. Then in the CSP selection, select OpenSC CSP and do not forgot to allow the CSP to interact with the user (or it will fail). ![image](https://user-images.githubusercontent.com/10632326/103347683-f83a0080-4a97-11eb-9342-bd862e29b4f6.png) mmc.exe then asks for the PIN. After a while, a new dialog appears to select a card, and only cancel can be pressed ![image](https://user-images.githubusercontent.com/10632326/103347693-fec87800-4a97-11eb-819b-d8e14b9804e4.png) It appears that Windows push its own container name, instead of using the smart card generated one. Then while trying to reload it, it fails. ![image](https://user-images.githubusercontent.com/10632326/103347751-261f4500-4a98-11eb-8869-80393bac6786.png) In short, Windows tries to create a container named test2-WIN-4O806IUONM0-CA Then try to access it after. Because the container cannot be accessed anymore, the PKI fails. Behind the scene, the MS Base CSP is trying to find a container on the card having this ID. Because it cannot find a container having this name, it crashes. You had a mechanism in the minidriver hooking this, by replacing on the fly the container ID by the Windows one. We can see it in the log: ![image](https://user-images.githubusercontent.com/10632326/103347786-3e8f5f80-4a98-11eb-8971-95efd186719e.png) However, in the failing call, the mapping table is not the same: image.png ![image](https://user-images.githubusercontent.com/10632326/103347793-43541380-4a98-11eb-961a-cb782b748301.png) meaning that the information has been lost. As a consequence, Windows cannot find the container named "test2 XXX" Indeed, we can see in the middle a reset of the PKI system because the container is closed after being created. ![image](https://user-images.githubusercontent.com/10632326/103347797-49e28b00-4a98-11eb-976a-cccc7c8b598c.png) There was a conversion table that was used to store that. (i designed it) https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L196-L202 ![image](https://user-images.githubusercontent.com/10632326/103347801-51099900-4a98-11eb-83ad-6b2d943856e4.png) Now replaced by https://github.com/OpenSC/OpenSC/blame/f443c391b03d06c821a7a725279c3cd135f9c13b/src/minidriver/minidriver.c#L860-L879 which pushed the container used by Windows to a prkey arg: ![image](https://user-images.githubusercontent.com/10632326/103347810-57981080-4a98-11eb-9cd2-98a30d3f4383.png) The table md_static_conversions is not used anymore, but instead the guid is used as the "direct" label. As a consequence, when the OpenSC dll is reloaded, the information is lost if this information is not saved to the card. So there was a move from a static variable to an instance one. Strangely, it works when using ADCS to generate a certificate on the smart card directly. (But I think it is using its own GUID instead of a self generated ID) ### Steps to reproduce I made a program which mimic the set of calls. Strangely, it works perfectly on Windows 10 (where the opensc-notif program is active), but not on my Windows 2008 R2 test domain (where this program is not active). ``` #include <windows.h> #include <wincrypt.h> #include <AccCtrl.h> #include <Aclapi.h> #pragma comment(lib, "Advapi32") #pragma comment(lib, "Ncrypt") #define CONTAINER L"test2-WIN-4O806IUONM6-CA" int _tmain(int argc, _TCHAR* argv[]) { HCRYPTPROV hProv = NULL; HCRYPTKEY hKey = NULL; if (!CryptAcquireContext(&hProv, CONTAINER, L"OpenSC CSP", PROV_RSA_FULL, CRYPT_MACHINE_KEYSET | CRYPT_NEWKEYSET)) { printf("CryptAcquireContext 1\r\n"); return -1; } if (!CryptGenKey(hProv, AT_KEYEXCHANGE, RSA1024BIT_KEY * 2, &hKey)) { printf("CryptGenKey 1\r\n"); return -1; } if (NCryptIsKeyHandle(hKey)) { printf("Not supposed to be here"); } PSECURITY_DESCRIPTOR pSD = (PSECURITY_DESCRIPTOR) LocalAlloc(0,SECURITY_DESCRIPTOR_MIN_LENGTH); if (!pSD) { printf("LocalAlloc 1\r\n"); return -1; } if (!InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION)) { printf("InitializeSecurityDescriptor 1\r\n"); return -1; } SID_IDENTIFIER_AUTHORITY sia = SECURITY_NT_AUTHORITY; PSID pSidSystem = NULL; PSID pSidAdmins = NULL; PACL pDacl = NULL; if (!AllocateAndInitializeSid(&sia, 1, SECURITY_LOCAL_SYSTEM_RID,0, 0, 0, 0, 0, 0, 0, &pSidSystem)) { printf("AllocateAndInitializeSid 1\r\n"); return -1; } // create Local Administrators alias SID if (!AllocateAndInitializeSid(&sia, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0,0, 0, &pSidAdmins)) { printf("AllocateAndInitializeSid 2\r\n"); return -1; } EXPLICIT_ACCESS ea[2]; ZeroMemory(&ea, sizeof(ea)); // fill an entry for the SYSTEM account ea[0].grfAccessMode = GRANT_ACCESS; ea[0].grfAccessPermissions = GENERIC_ALL; ea[0].grfInheritance = NO_INHERITANCE; ea[0].Trustee.MultipleTrusteeOperation = NO_MULTIPLE_TRUSTEE; ea[0].Trustee.pMultipleTrustee = NULL; ea[0].Trustee.TrusteeForm = TRUSTEE_IS_SID; ea[0].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP; ea[0].Trustee.ptstrName = (LPTSTR)pSidSystem; // fill an entry for the Administrators alias ea[1].grfAccessMode = GRANT_ACCESS; ea[1].grfAccessPermissions = GENERIC_ALL; ea[1].grfInheritance = NO_INHERITANCE; ea[1].Trustee.MultipleTrusteeOperation = NO_MULTIPLE_TRUSTEE; ea[1].Trustee.pMultipleTrustee = NULL; ea[1].Trustee.TrusteeForm = TRUSTEE_IS_SID; ea[1].Trustee.TrusteeType = TRUSTEE_IS_ALIAS; ea[1].Trustee.ptstrName = (LPTSTR)pSidAdmins; // create a DACL if (SetEntriesInAcl(2, ea, NULL, &pDacl) != ERROR_SUCCESS) { printf("SetEntriesInAcl 1\r\n"); return -1; } // Add the ACL to the security descriptor. if (!SetSecurityDescriptorDacl(pSD,TRUE,pDacl,FALSE)) { printf("SetSecurityDescriptorDacl 1\r\n"); return -1; } if (!SetSecurityDescriptorOwner(pSD,pSidAdmins,FALSE)) { printf("SetSecurityDescriptorOwner 1\r\n"); return -1; } if (!SetSecurityDescriptorGroup (pSD,pSidAdmins,FALSE)) { printf("SetSecurityDescriptorGroup 1\r\n"); return -1; } if (!CryptSetProvParam(hProv, PP_KEYSET_SEC_DESCR, (BYTE*)pSD, DACL_SECURITY_INFORMATION)) { printf("CryptAcquireContext 2\r\n"); return -1; } CryptDestroyKey(hKey); CryptReleaseContext(hProv, 0); printf("Sleeping 10s\r\n"); Sleep(10000); printf("Done Sleeping\r\n"); if (!CryptAcquireContext(&hProv, CONTAINER, L"OpenSC CSP", PROV_RSA_FULL, CRYPT_MACHINE_KEYSET)) { printf("CryptAcquireContext 2\r\n"); return -1; } printf("Container sucessfully reloaded\r\n"); return 0; } ``` ### Suggested solution Review the Windows container <-> OpenSC mapping table to see if it is of any use. (an information not related to the container, but on the process) ### Logs https://gist.github.com/vletoux/f9332cf2da42b2841c76551831dffb31

Anyway, getting out the following info might give some clues

C:\Windows\System32\certutil.exe -scinfo
C:\Windows\SysWOW64\certutil.exe -scinfo

mmfin · February 12, 2025, 6:26pm

Certutil - scinfo is able to communicate with the HSM2, correctly identifies the slot it seems, if you’d like output, I’ll see what I can do.

saper · February 12, 2025, 7:09pm

I think you might want to start preparing an issue for OpenSC with that information…

You might also want to give the following minidriver a try:

mmfin · February 14, 2025, 6:04am

@saper i’ve opened an issue 3341 in the OpenSC github, and have been discussing this issue with some additional investigation. an interesting observation was made related to the usage of OpenSC, sc-hsm-starterkit, which I think merits some review by Nitrokey, and I would appreciate some assistance in proceeding forward, where I currently appear to be stuck, without a way for the NitroKey to perform it’s desired function as the HSM for ADCS.

OpenSC 26.1 + NitrokeyHSM2 + Windows Certificate Authority (Server 2025, 2022, 2019) unable to select cryptography higher than SHA1 · Issue #3341 · OpenSC/OpenSC

please advise next steps.

saper · February 14, 2025, 10:52am

I think the last remark OpenSC 26.1 + NitrokeyHSM2 + Windows Certificate Authority (Server 2025, 2022, 2019) unable to select cryptography higher than SHA1 · Issue #3341 · OpenSC/OpenSC · GitHub deserves some attention, as there might be some confusion about the actual software being run, but I can judge it only on face value.

I am not Nitrokey and not using Windows, so here you are.