[Opendnssec-user] adding a zone, key processing fails

[Tom Hendrikx]

On 13/12/10 10:02, Sion Lloyd wrote:
> On Friday 10 Dec 2010 11:19:05 am Tom Hendrikx wrote:
>> Hi
> 
>> After the first run, ods-ksmutil key list -v shows:
>>
>> example.com                     KSK           publish   2010-12-10
>> 14:46:22       42c301bb477f383991323c08c02d40dc  SoftHSM NOT IN repository
>> example.com                     ZSK           active    2011-01-09
>> 11:46:22       f349cc85e0e1823f511f2467af4e75ff  SoftHSM NOT IN repository
> 
> This message indicates that the key in the kasp database is not in the HSM... 
> Was anything logged at the time that you added the new zone?

I did some more debugging, by installing 1.2.0rc2 on my desktop and
running add zone with verbosity there. I noticed that the HSM is called
to generate the keys, which succeeds. In the previously attached
logfile, the HSM is not called, which leads me to think that the KASP
database has knowledge of an already generated but still unused keys,
and tries to use them. These keys are for some reason missing from the HSM.

> 
>> I also just noticed that the key id (42c301bb477f383991323c08c02d40dc)
>> keeps coming back. I can remove a zone (ods-ksmutil zone delete) that
>> has this issue, remove all related files from /var/lib/opendnssec and
>> restart the suite. When I add a new zone with that was never used before
>> (example.com), the signer comes back again with this same key id.
> 
> Do you have shared keys turned on? If so this could be related to that plus 
> the error you have seen below.

SharedKeys is not enabled, and hasn't been enabled in the past.

> 
>> Another note is that when I try to remove the broken zone, I receive an
>> error that seems to indicate that the database is not correctly setup:
> 
> This should be fixed in trunk. It might be worth building from trunk and 
> removing the zone again.
> 
>> So, how do I recover from this issue? Note that there is a production
>> zone (however not very important) currently being signed by this setup
>> correctly, so starting from scratch is really a last resort.
> 
> I am not sure how this happened. After trying trunk the next thing I would do 
> is use hsmutil to confirm that the keys really do not exist in the repository. 
> Then see if anything was logged at the time that the new zone was added (and 
> the first run of the enforcer after that) to say why key generation failed. If 
> none of that turns up any useful information then if you send me (offlist) your 
> kasp.db then I can see if I can work out how this happened, and how to fix it.
> 

hsmutil (from both 1.2.0_rc1 and trunk at r4267) confirms that the keys are
not available in the HSM.

Adding example.com again after upgrading to trunk and restarting yields
the same results in both ksmutil output and logging: the keys with ids
42c301bb477f383991323c08c02d40dc and f349cc85e0e1823f511f2467af4e75ff
are assigned to the zone, but are not available in HSM).

Removing the zone does no longer yields the SQL error: this seems indeed
fixed in trunk, which is nice;)

Inspecting kasp.db does list the keys that are unknown to the HSM, even
after the re-adding and removal of zone example.com, which gets these
keys added to it. I'll send you the kasp.db off-list, but I assume that
it would be possible to use regular SQL to remove the missing keys from
the kasp.db 'keypairs' table?

--
Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20101213/c902af95/attachment.bin>