[Pki-users] Error 7 in SOkey enrollment

[Adewumi, Julius-p99373]

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 at redhat.com [mailto:pki-users-bounces at redhat.com]
On Behalf Of John Magne
Sent: Thursday, July 16, 2009 10:03 AM
To: Adewumi, Julius-p99373
Cc: pki-users at 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 at gdc4s.com>
To: "Christina Fu" <cfu at redhat.com>
Cc: pki-users at 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 at redhat.com] 
Sent: Wednesday, July 15, 2009 9:02 PM
To: Adewumi, Julius-p99373
Cc: pki-users at 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 at redhat.com
https://www.redhat.com/mailman/listinfo/pki-users

_______________________________________________
Pki-users mailing list
Pki-users at redhat.com
https://www.redhat.com/mailman/listinfo/pki-users