NSD and OpenDNSSEC under FreeBSD 10 [Part 5: SafeNet HSM]

This is the fifth part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

This time we’re going to integrate proper hardware HSM support in our setup — a pair of SafeNet Network HSMs (aka Luna SA).

Here is how our updated installation diagram looks like:

2016051701

Before we jump into technical details there are a couple of assumptions:

— I assume that HSMs are already configured and partitioned. HSM installation is outside of scope of this guide since it’s a lengthy and pretty time consuming process which has nothing to do with OpenDNSSEC. It also involves a big chunk of work to be done on the access federation field (different teams accessing different partitions with different PEDs or passwords). SafeNet HSM’s documentation is quite solid though, so make sure this part is completed. In our setup, both HSMs run the latest software 6.2.0-15 and there is one partition created on both units called TEST. TEST partition is activated and we’re going to create High Availability group, add both HSMs to the HA group and allow NS-SIGN to access it;

— As you might have noticed, I decided to leave ZSKs to be handled by SoftHSM. One of the things that you’ll have to keep an eye on with network HSMs is the HDD space. The way it works with SafeNet is that you have an appliance with some fixed amount of disk space (let’s say 2MB). Then you create partitions and allocate space out of total amount for each partition (by default it’s equal distribution). So let’s assume we created five partitions 417274 bytes each. Normally, storing a pair of public/private key consumes very little, but with OpenDNSSEC we’re talking about a number of domains each storing a pair of public/private keys for both KSK and ZSK. It’s very important to understand how far you can go, so you’re not surprised after several years when you discover that you run out of space.

Let’s do some basic math: one domain, with both ZSK (1024) and KSK (2048) stored on HSM, will consume 2768 bytes, so with 417274 bytes partition you should be able to handle ~150 domains. However, during ZSK or KSK rollover, another pair will be temporarily created, and although ZSK/KSK rollover shouldn’t happen at the same time and OpenDNSSEC will purge expired keys after the rollover is completed, you’ll have to consider extra 2768 bytes per domain (for a period of time defined in <Purge> stanza in kasp.xml), which leaves you 75 domains. As you can see this isn’t much. That’s why I decided to keep SoftHSM for ZSKs to save some HSM space (which is not cheap to say the least!).

One of the disadvantages of keeping both storage engines is that you’ll have one more dependency to worry about should you consider to upgrade (for example to SoftHSM2), hence the choice is yours. Another option would be to store private keys in HSM and leave public keys aside (<SkipPublicKey/> option under conf.xml), but I’ve read that it’s very much dependent on the HSM provider and could lead to unexpected results. And one more option would be to use <ShareKeys/> under kasp.xml — that way you can share the same key for multiple domains.

So, let’s access NS-SIGN, adjust the firewall policy, and install prerequisites first. In terms of ports, NS-SIGN will communicate with HSM-1 and HSM-2 using three ports: 1792/tcp, 1867/tcp and 22/tcp. Opening SSH is not strictly needed (it’s mainly for initial configuration) and will be removed once the integration is completed. 1792/tcp and 1867/tcp are mandatory though: 1792/tcp is used for Network Trust Link Service (NTLS), and 1867/tcp is used for a Network Trust Link (NTL) between a client and a partition. Since we’re using pf here is how it looks like:

  1. luna_hsm_services = "{ ssh, 1792, 1867 }"   # SafeNet Luna HSM ports
  2. table <luna_hsm> const { 10.9.128.42, 10.9.128.43 }
  3. # Outgoing traffic to SafeNet Luna HSMs
  4. pass out quick on xl0 inet proto tcp from xl0 to <luna_hsm> port $luna_hsm_services flags S/SA modulate state

Where 10.9.128.42 and 10.9.128.43 are IPs of our HSMs.

SafeNet HSM client software does support FreeBSD, but it’s compiled for FreeBSD 9 with libstdc++.so dependency, while I’m under FreeBSD 10. You will still be able to install and use it though.

Let’s install gcc first, to get libstdc++.so dependency resolved:

  1. % cd /usr/ports/lang/gcc && make install clean

Download SafeNet Luna HSM client package from the SafeNet website, unpack and copy the content of freebsd\9\64\ directory to NS-SIGN. We’ll need to install the following five packages:

  1. cmuFreebsd-6.2.0.tar.gz
  2. htl_clientFreebsd-6.2.0.tar.gz
  3. libcryptokiFreebsd-6.2.0.tar.gz
  4. lunacmFreebsd-6.2.0.tar.gz
  5. vtlFreebsd-6.2.0.tar.gz

Out of those five, libcryptoki is the only really needed by OpenDNSSEC. This is a PKCS #11 library through which OpenDNSSEC will communicate with the HSMs. Remaining four are SafeNet utilities and tools.

CMU is the SafeNet Certificate Management Utility. Could be useful if you want to deal with objects placed in the HSM (like to delete or to list an attribute).

HTL client (optional) is a quite important piece. HTL or Network Trust Link is used when you want to add additional protection layer on top of NTLS for virtual servers, to ensure that the HSM connects only to a trusted client instance that is in possession of a one-time-token generated by the HSM. Basically this is a service that constantly checks whether the link between NS-SIGN and HSM-1/2 is up and if it’s discovered to be down for more than 300 seconds NTLS is dropped and no communication to HSMs is possible anymore until you re-generate and re-import new tokens. In practical terms that means that you can reboot NS-SIGN no problem, but if someone clones it and then powers it on, they’ll most likely hit 300 seconds delay and HTL has to be re-established manually.

LunaCM is the SafeNet client-side administrative command interface for SafeNet HSMs. We’ll need it for creating HA groups.

VTL — the SafeNet Virtual Token Library is the legacy utility.

During the installation, you’ll get a time-out and packagesite mismatch error that could be ignored:

  1. % pkg install libcryptokiFreebsd-6.2.0.txz
  2.  
  3. Updating FreeBSD repository catalogue…
  4. Repository FreeBSD has a wrong packagesite, need to re-create database
  5. pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/latest/meta.txz: Operation timed out
  6. repository FreeBSD has no meta file, using default settings
  7. pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/latest/packagesite.txz: Operation timed out
  8. Unable to update repository FreeBSD
  9. All repositories are up-to-date.
  10. Repository FreeBSD has a wrong packagesite, need to re-create database
  11. pkg: Repository FreeBSD cannot be opened. 'pkg update' required
  12. Updating database digests format: 100%
  13. Checking integrity… done (0 conflicting)
  14. The following 1 package(s) will be affected (of 0 checked):
  15.  
  16. New packages to be INSTALLED:
  17.         libcryptokiFreebsd: 6.2.0
  18.  
  19. Proceed with this action? [y/N]: y
  20. [1/1] Installing libcryptokiFreebsd-6.2.0
  21. x libcryptoki/
  22. x libcryptoki/pkg-deinstall
  23. x libcryptoki/pkg-install
  24. x libcryptoki/libCryptoki2_64.so
  25. x libcryptoki/Chrystoki.conf
  26. x libcryptoki/Makefile
  27. x libcryptoki/pkg-descr
  28. Checking for /etc/Chrystoki.conf.bsdsave
  29. Copying default Chrystoki.conf file to /etc/
  30. Added ReceiveTimeout entry.
  31. Added SSLConfigFile entry.
  32. Added ClientPrivKeyFile entry.
  33. Added ClientCertFile entry.
  34. Added ServerCAFile entry.
  35. Added NetClient entry.
  36. Added TCPKeepAlive entry.
  37.  
  38. % pkg install cmuFreebsd-6.0.0.txz
  39.  
  40. % pkg install htl_clientFreebsd-6.0.0.txz
  41.  
  42. % pkg install lunacmFreebsd-6.0.0.txz
  43.  
  44. % pkg install vtlFreebsd-6.0.0.txz

Upon completion, you should have /usr/safenet/lunaclient directory created with bin/, cert/, htl/ and lib/ directories underneath. You’ll also have /etc/rc.d/htl_service and /etc/Chrystoki.conf files dropped.

Before we start with the configuration make sure that NS-SIGN, HSM-1 and HSM-2 have DNS entries registered and they can resolve each other using FQDNs. We’ll be dealing with certificates hence DNS names are crucial. In my example, they all have the following internal DNS names created: ns-sign.local.net, hsm-1.local.net and hsm-2.local.net.

Let’s start with the configuration. First, we need to copy server.pem certificate to NS-SIGN from both HSMs. So, from NS-SIGN:

  1. % cd /usr/safenet/lunaclient
  2.  
  3. % scp admin@hsm-1.local.net:server.pem cert/server
  4. admin@hsm-1.local.net password:
  5.  
  6. server.pem          100% 1172     1.1KB/s   00:00
  7.  
  8. % ./bin/vtl addServer -n hsm-1.local.net -c cert/server/server.pem -htl
  9.  
  10. New server hsm-1.local.net successfully added to server list.
  11.  
  12. % scp admin@hsm-2.local.net:server.pem cert/server
  13. admin@hsm-2.local.net password:
  14.  
  15. server.pem          100% 1172     1.1KB/s   00:00
  16.  
  17. % ./bin/vtl addServer -n hsm-2.local.net -c cert/server/server.pem -htl
  18.  
  19. New server hsm-1.local.net successfully added to server list.
  20.  
  21. % ./bin/vtl listServers
  22. Server: hsm-1.local.net HTL required: yes
  23. Server: hsm-2.local.net HTL required: yes

Now we need to generate NS-SIGN certificate and send it to both HSMs. From NS-SIGN:

  1. % cd /usr/safenet/lunaclient
  2.  
  3. % ./bin/vtl createCert -n ns-sign.local.net -c US -s NY -l NY -o ORG -u DEV
  4. Private Key created and written to: /usr/safenet/lunaclient/cert/client/ns-sign.local.netKey.pem
  5. Certificate created and written to: /usr/safenet/lunaclient/cert/client/ns-sign.local.net.pem
  6.  
  7. % scp cert/client/ns-sign.local.net.pem admin@hsm-1.local.net:
  8. admin@hsm-1.local.net password:
  9.  
  10. ns-sign.local.net.pem   100%  867     0.9KB/s   00:00
  11.  
  12. % scp cert/client/ns-sign.local.net.pem admin@hsm-2.local.net:
  13. admin@hsm-2.local.net password:
  14.  
  15. ns-sign.local.net.pem   100%  867     0.9KB/s   00:00

Enable HTL service on NS-SIGN by editing /etc/rc.conf:

  1. # enable htl
  2. htl_client_enable="YES"

The default /etc/rc.d/htl_service script didn’t work for me out of the box, therefore I had to modify it (# KEYWORD: shutdown):

  1. #!/bin/sh –
  2. #
  3. # Copyright (c) 2004  The FreeBSD Project
  4. # All rights reserved.
  5. #
  6. # Redistribution and use in source and binary forms, with or without
  7. # modification, are permitted provided that the following conditions
  8. # are met:
  9. # 1. Redistributions of source code must retain the above copyright
  10. #    notice, this list of conditions and the following disclaimer.
  11. # 2. Redistributions in binary form must reproduce the above copyright
  12. #    notice, this list of conditions and the following disclaimer in the
  13. #    documentation and/or other materials provided with the distribution.
  14. #
  15. # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS “AS IS'' AND
  16. # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  17. # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  18. # ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  19. # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  20. # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  21. # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  22. # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  23. # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  24. # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  25. # SUCH DAMAGE.
  26. #
  27. # $FreeBSD: release/9.2.0/etc/rc.d/mixer 242153 2012-10-26 18:06:49Z obrien $
  28. #
  29.  
  30. # PROVIDE: htl_service
  31. # REQUIRE: DAEMON
  32. # BEFORE: LOGIN
  33. # KEYWORD: shutdown
  34.  
  35. . /etc/rc.subr
  36.  
  37. name="htl_client"
  38. rcvar="htl_client_enable"
  39. stop_cmd="htl_client_stop"
  40. start_cmd="htl_client_start"
  41.  
  42. load_rc_config $name
  43. : ${htl_client_enable:=no}
  44.  
  45. htl_client_start()
  46. {
  47.    /usr/safenet/lunaclient/htl/htl_client
  48.    echo "Started Htl Service"
  49. }
  50.  
  51. htl_client_stop()
  52. {
  53.    HTLC_P=`pgrep -f htl_client`
  54.    if [ "$HTLC_P" != "" ] ; then
  55.         # First send a kill signal and wait a bit
  56.         kill $HTLC_P
  57.         sleep 10
  58.  
  59.         # If it is still running we now force kill it
  60.         HTLC_P=`pgrep -f htl_client`
  61.         if [ "$HTLC_P" != "" ] ; then
  62.             # try three times just in case
  63.             kill -9 $HTLC_P
  64.             kill -9 $HTLC_P
  65.             kill -9 $HTLC_P
  66.         else
  67.                 echo "OK"
  68.         fi
  69.    fi
  70. }
  71.  
  72. load_rc_config $name
  73. run_rc_command "$1"

I also modified the startup script of OpenDNSSEC to make sure that HTL service is started prior to OpenDNSSEC:

  1. % cat /usr/local/etc/rc.d/opendnssec | grep -i htl
  2. # REQUIRE: LOGIN DAEMON htl_service

Here is how you can check the startup order of services under FreeBSD by the way:

  1. % rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
  2. /etc/rc.d/htl_service
  3. /usr/local/etc/rc.d/opendnssec

Start the HTL service:

  1. % /etc/rc.d/htl_service start

SSH to HSM-1 and register the client. From HSM-1:

  1. [hsm-1] lunash:> client register -client ns-sign –hostname ns-sign.local.net -requirehtl -generateott
  2.  
  3. 'client register' successful.
  4.  
  5. Generating one-time token…
  6. One-time token for client ns-sign is ready to use.
  7. Filename is ns-sign.ott
  8.  
  9. Command Result : 0 (Success)
  10.  
  11. [hsm-1] lunash:>client hostip map -client ns-sign -ip 10.9.128.2
  12.  
  13. Command Result : 0 (Success)

‘client hostip map’ is not really needed. This is to ensure that even if DNS is down and HSMs cannot resolve ns-sign.local.net the link is still up by using the IP address.

SSH to HSM-2 and register the client. From HSM-2:

  1. [hsm-2] lunash:> client register -client ns-sign –hostname ns-sign.local.net -requirehtl -generateott
  2.  
  3. 'client register' successful.
  4.  
  5. Generating one-time token…
  6. One-time token for client ns-sign is ready to use.
  7. Filename is ns-sign.ott
  8.  
  9. Command Result : 0 (Success)
  10.  
  11. [hsm-2] lunash:>client hostip map -client ns-sign -ip 10.9.128.2
  12.  
  13. Command Result : 0 (Success)

ott files used to establish HTL have been generated and we need to transfer them to NS-SIGN. From NS-SIGN:

  1. % cd /usr/safenet/lunaclient
  2.  
  3. % scp admin@hsm-1.local.net:ns-sign.ott htl/hsm-1.local.net.ott
  4. admin@hsm-1.local.net password:
  5.  
  6. ns-sign.ott              100%   32     0.0KB/s   00:00
  7.  
  8. % scp admin@hsm-2.local.net:ns-sign.ott htl/hsm-2.local.net.ott
  9. admin@hsm-2.local.net password:
  10.  
  11. ns-sign.ott              100%   32     0.0KB/s   00:00

If everything is fine, you should see .key and .pem files created under htl/ directory for each HSM. From NS-SIGN:

  1. % cd /usr/safenet/lunaclient
  2.  
  3. % ls -al htl/hsm*
  4.  
  5. -rw-r–r–  1 root  wheel  1743 May 16 16:03 htl/hsm-1.local.net.key
  6. -rw-r–r–  1 root  wheel    32 May 18 16:54 htl/hsm-1.local.net.ott
  7. -rw-r–r–  1 root  wheel  1306 May 16 16:03 htl/hsm-1.local.net.pem
  8. -rw-r–r–  1 root  wheel  1751 May 16 16:03 htl/hsm-2.local.net.key
  9. -rw-r–r–  1 root  wheel    32 May 18 16:54 htl/hsm-2.local.net.ott
  10. -rw-r–r–  1 root  wheel  1306 May 16 16:03 htl/hsm-2.local.net.pem

Another way is to check it from one of the HSMs. From HSM-1:

  1. [hsm-1] lunash:>htl show
  2.  
  3. HTL Grace period   :  60 seconds
  4. Default OTT expiry :  300 seconds
  5.  
  6.  Client Name         HTL Status     OTT Status     OTT Expiry Time
  7.  —————————————————————–
  8.  ns-sign             Up             In use         300 (default)
  9.  
  10. Command Result : 0 (Success)

Now we need to assign TEST partition to NS-SIGN. SSH to HSM-1 and repeat the same from HSM-2:

  1. [hsm-1] lunash:>client assignPartition -client ns-sign -partition TEST
  2.  
  3. 'client assignPartition' successful.
  4.  
  5. Command Result : 0 (Success)
  6.  
  7. [hsm-2] lunash:>client assignPartition -client ns-sign -partition TEST
  8.  
  9. 'client assignPartition' successful.
  10.  
  11. Command Result : 0 (Success)

Finally we need to create HA group and add both HSMs into it. In order to create HA, we need to know the serials of the TEST partition. From NS-SIGN:

  1. % cd /usr/safenet/lunaclient
  2.  
  3. % ./bin/lunacm
  4. LunaCM v6.2.0-15. Copyright (c) 2006-2015 SafeNet, Inc.
  5.  
  6.         Available HSMs:
  7.  
  8.         Slot Id –>              0
  9.         HSM Label –>            TEST
  10.         HSM Serial Number –>    123456789
  11.         HSM Model –>            LunaSA 6.2.0
  12.         HSM Firmware Version –> 6.10.9
  13.         HSM Configuration –>    Luna SA Slot (PED) Signing With Cloning Mode
  14.         HSM Status –>           OK
  15.  
  16.  
  17.         Slot Id –>              1
  18.         HSM Label –>            TEST
  19.         HSM Serial Number –>    987654321
  20.         HSM Model –>            LunaSA 6.2.0
  21.         HSM Firmware Version –> 6.10.9
  22.         HSM Configuration –>    Luna SA Slot (PED) Signing With Cloning Mode
  23.         HSM Status –>           OK
  24.  
  25.         Current Slot Id: 0
  26.  
  27. lunacm:>hagroup createGroup -label TESTHA -serialNumber 123456789 -password XXXX-XXXX-XXXX-XXXX
  28.  
  29. Warning:  There are objects currently on the new member.
  30.           Do you wish to propagate these objects within the HA
  31.           group, or remove them?
  32.  
  33.           Type 'copy' to keep and propagate the existing
  34.           objects, 'remove' to remove them before continuing,
  35.           or 'quit' to stop adding this new group member.
  36.           > copy
  37.  
  38.         New group with label "TESTHA" created with group number 123456789.
  39.         Group configuration is:
  40.  
  41.          HA Group Label:  TESTHA
  42.         HA Group Number:  1234567890
  43.        HA Group Slot ID:  Not Available
  44.        Synchronization: enabled
  45.           Group Members:  123456789
  46.              Needs sync:  no
  47.         Standby Members:  <none>
  48.  
  49. Slot #    Member S/N                      Member Label    Status
  50. ======    ==========                      ============    ======
  51.      0     123456789                              TEST     alive
  52.  
  53. Command Result : No Error
  54.  
  55. lunacm:>hagroup addMember -group TESTHA -serialNumber 987654321 -password XXXX-XXXX-XXXX-XXXX
  56.  
  57. Warning:  There are objects currently on the new member.
  58.           Do you wish to propagate these objects within the HA
  59.           group, or remove them?
  60.  
  61.           Type 'copy' to keep and propagate the existing
  62.           objects, 'remove' to remove them before continuing,
  63.           or 'quit' to stop adding this new group member.
  64.           > copy
  65.  
  66.         Member 123456789 successfully added to group TESTHA. New group
  67.         configuration is:
  68.  
  69.          HA Group Label:  TESTHA
  70.         HA Group Number:  1234567890
  71.        HA Group Slot ID:  5
  72.        Synchronization: enabled
  73.           Group Members:  123456789, 987654321
  74.              Needs sync:  no
  75.         Standby Members:  <none>
  76.  
  77. Slot #    Member S/N                      Member Label    Status
  78. ======    ==========                      ============    ======
  79.      0     123456789                              TEST     alive
  80.      1     987654321                              TEST     alive
  81.  
  82.         Please use the command "ha synchronize" when you are ready
  83.         to replicate data between all members of the HA group.
  84.         (If you have additional members to add, you may wish to wait
  85.         until you have added them before synchronizing to save time by
  86.         avoiding multiple synchronizations.)
  87.  
  88. Command Result : No Error
  89.  
  90. lunacm:>exit

Note that XXXX-XXXX is the partition secret. It’s generated during HSM configuration phase (actually, when you create partitions).

The way HA organized with SafeNet might look a bit confusing. There is no clustering per se — both HSMs are actually not aware about each other. So if you place a file on the slot 0 of HSM-1 it will never be synced to HSM-2. HA is configured on the client side instead, so NS-SIGN, once it has something to commit, will sequentially write to a “virtual” slot 5 (labeled TESTHA) which will be propagated to both HSMs. If one of the HSMs is not available at the moment of commit, the client will keep retrying, and if fails, nothing will be committed.

Pay attention on how you label the HA slot — we’ll need it later on for OpenDNSSEC.

You might have also noticed a warning message about objects already present on the partition, so you have a choice to either ‘copy’ or ‘remove’ the content. This is because I have had some data already stored on the TEST partition. Be careful — if you type ‘remove’ all data will be destroyed, so if you share TEST partition with other services/servers like I do always use ‘copy’.

You can have a look at /etc/Chrystoki.conf file, which should be updated with your HSMs and HA slot:

  1. Chrystoki2 = {
  2.    LibUNIX = /usr/lib/libCryptoki2.so;
  3.    LibUNIX64 = /usr/lib/libCryptoki2_64.so;
  4. }
  5.  
  6. Luna = {
  7.   DefaultTimeOut = 500000;
  8.   PEDTimeout1 = 100000;
  9.   PEDTimeout2 = 200000;
  10.   PEDTimeout3 = 10000;
  11.   KeypairGenTimeOut = 2700000;
  12.   CloningCommandTimeOut = 300000;
  13.   CommandTimeOutPedSet = 720000;
  14. }
  15.  
  16. CardReader = {
  17.   RemoteCommand = 1;
  18. }
  19.  
  20. Misc = {
  21.   PE1746Enabled = 0;
  22.    ToolsDir = /usr/safenet/lunaclient/bin;
  23. }
  24. LunaSA Client = {
  25.    ReceiveTimeout = 20000;
  26.    SSLConfigFile = /usr/safenet/lunaclient/bin/openssl.cnf;
  27.    ClientPrivKeyFile = /usr/safenet/lunaclient/cert/client/ns-sign.local.netKey.pem;
  28.    ClientCertFile = /usr/safenet/lunaclient/cert/client/ns-sign.local.net.pem;
  29.    ServerCAFile = /usr/safenet/lunaclient/cert/server/CAFile.pem;
  30.    NetClient = 1;
  31.    TCPKeepAlive = 1;
  32.    ServerName00 = hsm-1.local.net;
  33.    ServerPort00 = 1792;
  34.    ServerHtl00 = 1;
  35.    ServerName01 = hsm-2.local.net;
  36.    ServerPort01 = 1792;
  37.    ServerHtl01 = 1;
  38. }
  39. VirtualToken = {
  40.    VirtualToken00Label = TESTHA;
  41.    VirtualToken00SN = 1234567890;
  42.    VirtualToken00Members = 123456789,987654321;
  43. }
  44. HASynchronize = {
  45.    TESTHA = 1;
  46. }

Another interesting test would be to reboot NS-SIGN and monitor htl status on one of the HSMs. You will notice that the status would change to ‘Grace period’ and back to ‘Up’ once NS-SIGN is up:

  1. [hsm-1] lunash:>htl show
  2.  
  3. HTL Grace period   :  60 seconds
  4. Default OTT expiry :  300 seconds
  5.  
  6.  Client Name         HTL Status     OTT Status     OTT Expiry Time
  7.  —————————————————————–
  8.  ns-sign             Grace period   In use         300 (default)
  9.  
  10. Command Result : 0 (Success)
  11.  
  12. [hsm-1] lunash:>htl show
  13.  
  14. HTL Grace period   :  60 seconds
  15. Default OTT expiry :  300 seconds
  16.  
  17.  Client Name         HTL Status     OTT Status     OTT Expiry Time
  18.  —————————————————————–
  19.  ns-sign             Up             In use         300 (default)
  20.  
  21. Command Result : 0 (Success)

By the way, if for some reason you lose HTL link, you can always regenerate ott files on HSMs. You will have to transfer new ott files to NS-SIGN using the same procedure as mentioned above:

  1. [hsm-1] lunash:>htl generateOtt -client ns-sign

To summarize: NS-SIGN is fully registered and ready to use SafeNet Network HSMs. OpenDNSSEC hasn’t been configured yet and is not aware about HSMs — that’s what we’re going to do tomorrow.

Tags: , , , , , , , , , ,

Leave a Reply