[Opendnssec-user] Error converting from 1.4.14 to 2.1.8

[(Berry) A.W. van Halderen]

On Fri, Mar 05, 2021 at 12:58:16AM +0100, Havard Eidnes via Opendnssec-user wrote:
> 1) We're using <NSEC3> for denial-of-existence.  NSEC3 uses a
> "salt" value as an input value to the process.  If we move away
> the old /var/opendnssec/signconf/ directory and create it anew,
> OpenDNSSEC will populate it with an xml file per zone.  However,
> they all have this part:
> 
>     <Denial>
>       <NSEC3>
>         <Hash>
>           <Algorithm>1</Algorithm>
>           <Iterations>5</Iterations>
>           <Salt>0</Salt>
>         </Hash>
>       </NSEC3>
>     </Denial>

Okay that salt is clearly wrong, is should be a hex string.  I need
to check where this comes from, which takes a bit of time.  Did you
have an explicit salt specified in your 1.4 installation?
So instead of
   <Salt length="8"/>
You had 
   <Salt>cd79fa0214ff93b7</Salt>
in your kasp.xml?  Are the kasp.xml from the old and new installation
essentially the same?

> Now, the old signconf files typically *do* have a non-zero salt
> value, e.g.
>                 <Denial>
>                         <NSEC3>
>                                 <Hash>
>                                         <Algorithm>1</Algorithm>
>                                         <Iterations>5</Iterations>
>                                         <Salt>cd79fa0214ff93b7</Salt>
>                                 </Hash>
>                         </NSEC3>
>                 </Denial>
> and I suspect this data is just a reflection of what's in the
> kasp.db file.

Yes it is.

> So ... did the NSEC3 not get converted / transferred to the new
> kasp.db file in the conversion?  Why does it end up as the
> single-character 0 in OpenDNSSEC 2?  It ended up as "0" in the
> policy table in the converted kasp.db file.  Should it instead
> have been NULL or the empty string?

It should not have ended up as a single character 0 in the database.
Did you query this in the database table?

> One of my colleagues who helped me doing the conversion used
> sqlite3 to change the global config in kasp.db to use NSEC
> instead of NSEC3, and that seemed to have brought the process
> further along.

Ehm... I'm confused, you migrated from NSEC3 to NSEC using a database
change?  That seems dangerous.
Was this in order to prevent a problem or a deliberate change.  I'm
not sure which side effects this could have.  And was this done
before or after the migration?

> 2) We seem to have issues related to SoftHSM2, which we're
> converting to at the same time.  The problem we're having is that
> the level of error messages related to SoftHSM2 is nearly binary:
> either it works or it doesn't, and not a word about "why" when it
> doesn't.  As an operator this leaves me stumped about what's
> really going on and what possible correction can be made.
> 
> Mar  4 22:28:50 tilfeldigvis ods-signerd: [zone] unable to publish keys for zone 0.0.1.0.0.0.0.0.0.0.7.0.1.0.0.2.ip6.arpa: error creating libhsm context
> Mar  4 22:28:50 tilfeldigvis ods-signerd: [tools] unable to read zone 0.0.1.0.0.0.0.0.0.0.7.0.1.0.0.2.ip6.arpa: failed to publish dnskeys (HSM error)

It cannot access or find the keys.  If using SoftHSM it means the keys aren't
there at all, or are not readable.

[..]
> of any errors (it's a library, according to the name), and
> _hsm_ctx isn't readily available in the file which calls
> hsm_create_context(), so the opportunity of getting a proper
> error message to explain *why* the HSM module is unhappy is lost.
> I would call this an "interface design error".

Error reporting isn't the best, but on the other hand the errors
retrieved through the PKCS#11 interface won't help.  SoftHSM will
also perform error reporting, which can often be usefull now.  This
will happen especially during startup, less during actual access.

> Now, I'm not entirely certain how one might go about verifying
> that the HSM module is happy with the SoftHSM2 database.

Running "ods-hsmutil list" is the easiest way to verify whether
OpenDNSSEC can access the HSM.

> ods @ tilfeldigvis: {27} ods-migrate
> Reading config file '/usr/pkg/etc/opendnssec/conf.xml'..
> Connecting to HSM..
> Connecting to database..
> Computing keytags, this could take a while.
> Added keytags for 1653 keys.
> Finishing..
> ods@ tilfeldigvis: {28} 
> 
> and took nearly 70 CPU minutes (yikes!)

That seems excessive, but it is an expensive operation.  Since this
is a migration step I'll keep it at that.

> Also, ods-enforcer is showing all the keys -- an example:
[..]
> However, I'm not sure whether listing the keys actually causes
> access to the SoftHSM.

No, the enforcer only accesses an HSM in generating keys, never afterwards.

> Is there anything else I can/should do to
> minimally verify that the SoftHSM2 module is working as intended?
> So ... this leaves me without any answer as to what might be
> wrong and what I ought to do about it.  Help!

A common problem is related to file access permissions.  If the migration
happened for instance as a different user then which is used to run
OpenDNSSEC, then files may no longer be accessible due to permission
problems.

\Berry