We got a box of these Gemalto cards, and here is the only info inside the box: Cyberflex www.cyberflex.com gemalto Key: Value (hexadecimal - no spaces) Auth: 404142434445......4E4F MAC: 404142434445......4E4F KEK: 404142434445......4E4F Warning: Ten failed attempts will render this card useless. Gemalto does not replace blocked cards. You see, there is no Model number or nothing on them. They are white and blank cards with Just the chip embed. From: Julius Adewumi @GDC4S.com Ph:480-441-6768 Contract Corp:MTSI -----Original Message----- From: pki-users-bounces@redhat.com [mailto:pki-users-bounces@redhat.com] On Behalf Of John Magne Sent: Thursday, July 16, 2009 10:03 AM To: Adewumi, Julius-p99373 Cc: pki-users@redhat.com Subject: Re: [Pki-users] Error 7 in SOkey enrollment Is there any chance you are using a webstore gemalto card? You may be using a version of CS that requires a specific version of this Gemalto card. ----- Original Message ----- From: "Julius-p99373 Adewumi" <Julius.Adewumi@gdc4s.com> To: "Christina Fu" <cfu@redhat.com> Cc: pki-users@redhat.com Sent: Thursday, July 16, 2009 9:37:54 AM GMT -08:00 US/Canada Pacific Subject: RE: [Pki-users] Error 7 in SOkey enrollment Thanks. Is there any config change that will rectify this? I see the log says it receives public key (from the token) in response to the "generate priv key on token" request, and the first failure logged was that "Parsing of the public key failed". I thought a different smartcard reader or different smartcard will prove something. I changed to a different reader and the problem persisted. If I can use a different model of smartcards and the problem persists, I will conclude it's the TPS (Certificate Systems software). Am I missing something in my analysis? From: Julius Adewumi @GDC4S.com Ph:480-441-6768 Contract Corp:MTSI -----Original Message----- From: Christina Fu [mailto:cfu@redhat.com] Sent: Wednesday, July 15, 2009 9:02 PM To: Adewumi, Julius-p99373 Cc: pki-users@redhat.com Subject: Re: [Pki-users] Error 7 in SOkey enrollment Adewumi, Julius-p99373 wrote:
Has anyone familiarity with the following VFY_CreateContext() failure
or the verifyProof failure who can shed some light on what is going on, config or software release version --suspect is certEnroll()?
The proof verification is for proving that the token does have the private key that goes with the public key in the cert request. Like you have observed, the userKey profile's encryption cert by default has the server generate the keys, therefore does not need the proof verification. The signing cert does generate keys on the token itself, thus causes the proof verification. And you can see the success proof verification like the following: [2009-07-15 15:53:55] a3c21b8 CertEnroll::verifyProof - verify proof begins [2009-07-15 15:53:55] a3c21b8 CertEnroll::verifyProof - VFY_CreateContext() succeeded [2009-07-15 15:53:55] a3c21b8 CertEnroll::verifyProof - VFY_End() returned 0 If you try changing the userKey profile's encryption cert to generate the keys on the token instead, such as: op.enroll.userKey.keyGen.encryption.serverKeygen.enable=false You will notice now that you have both signing and encryption cert requests going through the verifyProof (2 sets of the above messages in log). It seems like in the security officer case, the proof somehow is incorrect, thus failed the verifyProof check on TPS. Further investigation is needed. Christina _______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users