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
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
