Hi Steve, I have no clue of Windows CA/PKI so I am also unable to provides any hints on this, but - as the error message from OpenSSL says "signature failure" this really indicates that the signature is calculated wrong OR openssl uses the wrong public key to validate it which MIGHT be a side effect of missing AKI/SKI items but makes otherwise not much sense as I would expect openssl to simply not construct the chain.
As Martin already said we would really be interessted to get hands on some "broken" certificates to have a deeper look whats going on here and of course we would be happy if you share your insights from getting this to work. As we just recently build up an OpenXPKI using a complete secp384r1 chain I can confirm that it works, Oliver Am 05.10.20 um 02:43 schrieb Steve Downey via OpenXPKI-users: > 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 -- Protect your environment - close windows and adopt a penguin! _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
