Hi there Debian 10
root@can-lx-intca-01:/etc/openxpki# openssl version OpenSSL 1.1.1d 10 Sep 2019OpenSSL Yes I truncated the output to show the certificate signature, as it seems to be in question, you're only missing AIA/CRL info really. I traced this to the root certificate itself, issued from Microsoft Certificate services. The import of the SubCA Cert is validating the chain (looked up the validate code on Git), when it hit's the root, then there is the signature failure. Since the SubCA Key and CSR were generated by OpenSSL to be signed by Windows, I would be very surprised if that one failed. This I think is something related to your *strange* things. I've seen an oddity where Microsoft has no AKI in it's root to indicate it's a self-signed root, but OpenSSL does. When then trying to validate against a Gemlato HSM (based on OpenSSL), the Client auth would fail because the chain couldn't be validated, Microsoft validates against the SKI, thus no need to an AKI. Im playing on generating a new Self-Signed using the Windows x509 interface ( https://www.sysadmins.lv/blog-en/self-signed-certificate-creation-with-powershell.aspx ) and importing, if I can get OpenSSL to validate it. None of the GUI tools allow to add all the required extensions and I don't see any other way to generate an ECC key with the CLI in windows. root@can-lx-intca-01:/etc/openxpki# openssl verify -check_ss_sig /etc/openxpki/ca/rootCA.crt -verbose DC = net, DC = enterprises, OU = pki, CN = CAN-ROOTCA-01 error 18 at 0 depth lookup: self signed certificate DC = net, DC = enterprises, OU = pki, CN = CAN-ROOTCA-01 error 7 at 0 depth lookup: certificate signature failure error /etc/openxpki/ca/lawlrootCA.crt: verification failed 140257458152576:error:0D0C50C7:asn1 encoding routines:ASN1_item_verify:unknown signature algorithm:../crypto/asn1/a_verify.c:121: it seems that my bit level might not be entirely compatible, I've seen other references googling around that say P384 should be the max. If I follow the pointers here, https://security.stackexchange.com/questions/158676/four-ecdsa-p256-csps-are-available-in-windows-which-one-should-i-use/202856 So my provider being P-521 may not be "fully" supported despite openssl ecparam -list_curves listing secp521r1 as a supported curve. and I think I have the right curves if this is correct: https://crypto.stackexchange.com/questions/70927/naming-convention-for-nist-elliptic-curves-in-openssl Summary: - generate new self signed with PSPKI and use curve P-384 instead of P-521 (maybe even a seperate P-256 curved key) and validate with "openssl validate -check_ss_sig" - if openssl validate, import new root cert to sign against, Reduce KSP from P-521 to P-384 if I still want to maintain high encryption I ( change public signing to match P-384 (registry entry) ) Make sense? _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
