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(a)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