(jdoe@example:~) voms-proxy-init
Enter GRID pass phrase for this identity:
Credentials couldn't be loaded [/home/jdoe/.globus/userkey.pem, /home/jdoe/.globus/usercert.pem]: Provided private key is not matching the certificate
No credentials found!
I've tested both canl/2.5.0 with bcprov/1.58.0 bcpkix/1.58.0.0 as shipped with voms-proxy-init, as well as the latest canl-java (2.6.0) in combination with BouncyCastle 1.61 (using a custom build of voms-api-java) but the result stays the same.
Using a p12 file using voms-proxy-init does work, but probably doesn't involve the same check in canl-java (where it compares key and cert).
I've attached cert_testdir.zip containing a bogus certificate from a bogus CA with the same type of key one gets from the TCS.
All passphrases are test. You can test it by unpacking, then run
The new TCS (see https://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx) allows one to create EC keys. By default one downloads a p12 file, which can then be converted into a pem cert and key using openssl pkcs12. The resulting pem key however cannot be read by java-based voms-proxy-init. The error traces back to canl-java at KeyAndCertCredential.java#L54_L60, i.e. one sees the error:
I've tested both canl/2.5.0 with bcprov/1.58.0 bcpkix/1.58.0.0 as shipped with voms-proxy-init, as well as the latest canl-java (2.6.0) in combination with BouncyCastle 1.61 (using a custom build of voms-api-java) but the result stays the same.
Using a p12 file using voms-proxy-init does work, but probably doesn't involve the same check in canl-java (where it compares key and cert).
I've attached cert_testdir.zip containing a bogus certificate from a bogus CA with the same type of key one gets from the TCS. All passphrases are test. You can test it by unpacking, then run
and