DNS安全扩展(DNS Security Extensions —— DNSSEC)提供可靠的保护,防止缓存中毒(cache poisoning)攻击。同时,这些扩展还提供了其他好处:它们限制了随机子域攻击对解析器缓存和权威服务器的影响,并为身份验证和私人电子邮件传输等现代应用程序提供了基础。
为了实现这一目标,DNSSEC在权威DNS区域的DNS记录中添加数字签名,DNS解析器验证接收到的记录上签名的有效性。如果签名与接收到的数据匹配,解析器可以确保数据在传输过程中没有被修改。
注: DNSSEC和传输级加密是互补的!与DNS-over-TLS、DNS-over-HTTPS或VPN等典型的传输级加密不同,DNSSEC使DNS记录在DNS解析链的所有点上都是可验证的。
本节重点介绍使用BIND部署DNSSEC的方法。有关DNSSEC原理的更深入讨论(例如DNSSEC如何更改DNS查找?),请参阅DNSSEC指南。
第五章:DNSSEC5.1. 区域签名5.1.1. 区域密钥5.1.2. 全自动(密钥和签名策略)5.1.2.1. 密钥翻转5.1.2.2. 多签名者模型5.1.3. 手工签字5.1.4. 使用私有类型记录进行监控5.2. 安全委派5.3. DNSSEC 验证5.3.1. 验证失败5.3.2. 与未签名(不安全)区域共存5.4. 动态信任锚管理5.4.1. 正在验证解析器5.4.2. 权威服务器5.5. PKCS#11 (Cryptoki) 支持5.5.1. 先决条件5.5.2. 构建 SoftHSMv25.5.3. 使用 engine_pkcs11的OpenSSL 1.x.x 5.5.4. 配置 engine_pkcs115.5.5. 在BIND命令中启用OpenSSL引擎5.5.6. OpenSSL 3 和 pkcs11-provider5.5.7. 配置 pkcs11-provider5.5.8. 密钥生成5.5.9. 使用自动区域重新签名运行named
BIND提供了几种方法来生成签名并在DNS区域的生命周期内保持其有效性:
无论使用哪种区域签名方法,加密密钥都存储在名为 Kdnssec.example.+013+12345.key
和 Kdnssec.example.+013+12345.private
的文件中。私钥(位于.private文件中)用于生成签名,公钥(位于.key文件中)则用于签名验证。此外,全自动(密钥和签名策略)方法创建了第三个文件 Kdnssec.example+013+12345.state
,用于跟踪DNSSEC密钥定时并安全地执行密钥翻转。
文件名包含:
dnssec.example.
),警告: 完全灾难恢复需要私钥。将关键文件备份到安全位置,防止未经授权的访问。任何有权访问私钥的人都可以创建虚假但看似有效的DNS数据。
密钥和签名策略(Key and Signing Policy —— KASP)是一种配置方法,描述了如何维护DNSSEC签名密钥以及如何对区域进行签名。
这是推荐的、完全自动化的DNS区域签名和维护方式。对于大多数用例,用户可以简单地使用内置的默认策略,该策略应用了最新的DNSSEC实践:
zone "dnssec.example" {
type primary;
file "dnssec.example.db";
dnssec-policy default;
};
dnssec-policy
声明要求设置动态DNS或启用 inline-signing
。在上面的示例中,我们使用后者,因为 default
策略使用 inline-signing
。
这足以创建必要的签名密钥,并为该区域生成 DNSKEY
、 RRSIG
和 NSEC
记录。BIND还负责此区域的任何DNSSEC维护,包括替换即将过期的签名和管理密钥翻转(Key Rollovers)。
注:
dnssec-policy
需要对该区域的写访问权限。有关区域存储影响的更多详细信息,请参阅dnssec-policy
。
默认策略创建一个密钥,用于对整个区域进行签名,并使用 NSEC
启用经过身份验证的拒绝存在(一种安全的方式来判断区域中不存在哪些记录)。建议使用此政策,通常不需要更改。
如果需要,可以通过在配置中添加 dnssec-policy
语句来定义自定义策略:
xxxxxxxxxx
dnssec-policy "custom" {
dnskey-ttl 600;
keys {
ksk lifetime P1Y algorithm ecdsap384sha384;
zsk lifetime 60d algorithm ecdsap384sha384;
};
nsec3param iterations 0 optout no salt-length 0;
};
例如,此 custom
策略:
DNSKEY
TTL(600秒)DNSKEY
、 CDS
和 CDNSKEY
)进行签名,另一个区域签名密钥(Zone Signing Key —— ZSK)对区域的其余部分进行签名。KSK在一年后自动轮换,ZSK在60天后自动轮换。而且:
有关KASP配置的更多信息,请参阅 dnssec-policy
。
DNSSEC指南中的“Advanced Discussions”部分讨论了各种策略设置,可能有助于确定特定需求的值。
使用 dnssec-policy
时,可以设置密钥生存期(key lifetime)以触发密钥翻转。ZSK翻转是全自动的,但对于KSK和CSK翻转,需要向家长提交DS记录。有关可能的方法,请参阅安全委派(Secure Delegation)。
一旦DS在父密钥中(并且前导密钥的DS被撤回),BIND需要被告知此事件已经发生。这可以通过配置家长代理自动完成:
xxxxxxxxxx
zone "dnssec.example" {
type primary;
file "dnssec.example.db";
dnssec-policy default;
parental-agents { 192.0.2.1; };
checkds explicit;
};
这里为BIND配置了一个服务器 192.0.2.1
,用于向其发送DS查询,以便在密钥翻转期间检查DS RRset的 dnssec-example
。这需要是一个受信任的服务器,因为BIND不会验证响应。checkds
选项使BIND使用显式配置的父代理,而不是通过查询父NS记录来查找它们。
如果设置父代理是不可取的,也可以告诉BIND DS是在父代理中发布的:rndc dnssec -checkds -key 12345 published dnssec.example.
。并且前任密钥的DS已被删除,其中: rndc dnssec -checkds -key 54321 withdrawn dnssec.example
。其中12345和54321分别是后继密钥和前导密钥的密钥标签。
要比计划更早地滚动密钥,或滚动具有无限生命周期的密钥,请使用:rndc dnssec -rowloon -key 12345 dnssec.example.
。
要将签名区域还原为不安全区域,请更改区域配置以使用内置的“不安全”策略。详细说明请参见“还原为未签名”(Reverting to Unsigned)。
动态区域提供了由多个提供者对区域进行签名的能力,这意味着每个提供者独立地对同一区域进行签名和服务,如 RFC 8901 中所述。BIND 9能够支持Model 2,其中每个提供商都有自己的KSK和ZSK(或CSK)。其他提供者的密钥可以通过动态更新导入。对于每个活动的KSK,父区域中必须有一个相应的DS记录。密钥翻转需要协调才能更新DS和DNSKEY RRset。
有几种工具可用于手动签署区域。
警告: 请注意,手动程序主要用于向后兼容性,只有有特定需求的专家用户才能使用。
要手动设置DNSSEC安全区域,必须遵循一系列步骤。有关更多信息,请参阅DNSSEC指南中的“手动签名”一章。
签名过程的状态由私有类型记录(默认类型值为65534)发出信号。签名完成后,具有非零初始八位字节的记录的最后一个八位字节具有非零值。
如果私有类型记录的第一个八位字节为非零,则该记录表示需要使用与记录匹配的密钥对区域进行签名,或者应删除与记录匹配地所有签名。以下是第一个八位字节的不同值的含义:
只有标记为“complete”的记录才能通过动态更新删除;删除其他私有类型记录的尝试将被自动忽略。
如果第一个八位字节为零(这是一个不应出现在 DNSKEY
记录中的保留算法号),则该记录表示正在对 NSEC3
链进行更改。记录的其余部分包含 NSEC3PARAM
记录,而标志字段告诉根据标志位执行什么操作:
0x01 OPTOUT
0x80 CREATE
0x40 REMOVE
0x20 NONSEC
在权威服务器上对区域进行签名后,最后一步是在父区域(例如)和本地区域(dnssec.example)之间建立信任链。
一般来说,程序是:
dnssec.example.
DS记录)。有多种方法可以更新父区域中的DS记录。请参阅父区域的文档,了解哪些选项适用于给定的案例区域。一般来说,从最推荐到最不推荐的选项是:
CDS
/ CDNSKEY
记录自动更新父区域中的DS记录。这需要在父区域、注册表或注册器中支持 RFC 7344。在这种情况下,配置BIND以监视父区域中的DS记录,一切都会在正确的时间自动发生。dig
在区域中查询自动生成的 CDS
或 CDNSKEY
记录,然后使用父区域指定的方法(web表单、电子邮件、API…)将这些记录插入父区域。dnssec-dsfromkey
实用程序手动生成DS记录,然后将它们插入父区域。BIND解析器默认验证来自权威服务器的答案。此行为由配置语句 dnssec-validation
控制。
默认情况下,使用DNS根区域的信任锚点。此信任锚作为BIND的一部分提供,并使用动态信任锚管理保持最新状态。
注: DNSSEC验证“开箱即用”,不需要额外配置。其他配置选项仅适用于特殊情况。
为了验证答案,解析器需要至少一个受信任的起点,即“信任锚”。本质上,信任锚是用于形成加密信任链中第一个链接的区域的 DNSKEY
RR的副本。可以使用 trust-anchors
指定替代信任锚,但这种设置非常不寻常,建议仅供专家使用。有关更多信息,请参阅DNSSEC指南中的信任锚。
BIND权威服务器在加载时不验证签名,因此不需要在配置文件中指定权威区域的区域密钥。
配置DNSSEC验证后,解析器会拒绝来自签名的安全区域的任何未验证的答案,并向客户端返回SERVFAIL。
响应可能因多种原因而无法验证,包括签名丢失、过期或无效;与父区域中的DS RRset不匹配的密钥;或者来自一个区域的不安全响应,根据其父区域的说法,该响应应该是安全的。
有关更多信息,请参阅基本DNSSEC故障排除。
不受DNSSEC保护的区域称为“不安全”,这些区域与已签名区域无缝共存。
当验证器收到来自具有已签名父区域的未签名区域的响应时,它必须与父区域确认该区域是故意未签名的。它通过签名和验证的NSEC/NSEC3记录验证父区域是否不包含子区域的DS记录来实现这一点。
如果验证器可以证明该区域是不安全的,则接受响应。然而,如果不能,验证器必须假设不安全的响应是伪造的;它拒绝响应并记录错误。
记录的错误为“不安全证明失败”和“收到不安全响应;父级表示它应该是安全的”
BIND能够使用 RFC 5011 密钥管理来维护DNSSEC信任锚。此功能允许 named
跟踪关键DNSSEC密钥的更改,而无需操作员对配置文件进行任何更改。
要配置验证解析器以使用 RFC 5011 来维护信任锚,请使用 trust-anchors
语句和 initial-key
关键字来配置信任锚。关于这一点的信息可以在 trust-anchors
声明描述中找到。
要为 RFC 5011 信任锚维护设置权威区域,请为该区域生成两个(或多个)密钥签名密钥(key signing keys —— KSK)。与其中一个签署区域;这就是“主动(active)”KSK。所有未签署该区域的KSK都是“备用(stand-by)”密钥。
任何配置为使用活动KSK作为 RFC 5011 托管信任锚的验证解析器都会记录该区域DNSKEY RRset中的备用KSK,并将其存储以供将来参考。解析器定期重新检查该区域;30天后,如果新密钥仍然存在,则解析器会接受该密钥作为该区域的有效信任锚。在30天接受定时器完成后的任何时候,都可以撤销活动的KSK,并将该区域“滚动”到新接受的密钥。
在区域中放置备用密钥的最简单方法是使用 dnssec-keygen
和 dnssec-signzone
的“智能签名”功能。如果密钥的发布日期是过去的,但激活日期是未设置的或将来的,dnssec-signzone -S
会在区域中包含DNSKEY记录,但不会使用它进行签名:
xxxxxxxxxx
$ dnssec-keygen -K keys -f KSK -P now -A now+2y example.net
$ dnssec-signzone -S -K keys example.net
要撤销密钥,请使用命令 dnssec revoke
。这将REVOKED位添加到密钥标志中,并重新生成 K*.key
和 K*.private
文件。
撤销活动密钥后,必须使用撤销的KSK和新的活动KSK对区域进行签名。智能签名会自动处理此问题。
一旦密钥被撤销并用于对其出现的DNSKEY RRset进行签名,解析器将不再接受该密钥作为有效的信任锚。但是,可以使用新的活动密钥进行验证,该密钥在作为备用密钥时被解析器接受。
有关密钥翻转场景的更多详细信息,请参阅 RFC 5011 。
当一个密钥被撤销时,它的密钥ID会发生变化,增加128,并在65535处环绕。例如,密钥“ Kexample.com.+005+10000
”变为“ Kexapple.com.+005+10128
”。
如果两个密钥的ID相距128,其中一个密钥被撤销,则这两个密钥ID将发生冲突,从而导致几个问题。为了防止这种情况,如果存在可能发生冲突的另一个密钥, dnssec-keygen
不会生成新的密钥。仅当新密钥写入到包含该区域使用的所有其他密钥的同一目录时,才会发生此检查。
旧版本的BIND 9没有这种保护。如果对以前版本生成的密钥使用密钥吊销,或者使用存储在多个目录或多台计算机上的密钥,请务必小心。
预计BIND 9的未来版本将以不同的方式解决这个问题,通过将撤销的密钥与其原始的未撤销密钥ID一起存储。
公钥加密标准#11(Public Key Cryptography Standard —— PKCS#11)定义了一个依赖于平台的API,用于控制硬件安全模块(hardware security modules —— HSMs)和其他加密支持设备。
PKCS#11使用“提供者库”:一个动态可加载的库,它提供了一个低级PKCS#11接口来驱动HSM硬件。PKCS#11提供程序库来自HSM供应商,它特定于要控制的HSM。
BIND 9通过OpenSSL扩展访问PKCS#11库。OpenSSL3及更新版本的扩展名是pkcs11-provider;对于较旧的OpenSSL版本,可以使用OpenSC项目中的engine_pkcs11。
在这两种情况下,扩展都是动态加载到OpenSSL中的,HSM是间接操作的;HSM不支持的任何加密操作都可以由OpenSSL执行。
有关安装、初始化、测试和排除HSM故障的信息,请参阅HSM供应商提供的文档。
SoftHSMv2是SoftHSM的最新开发版本,可从以下网址获得https://github.com/opendnssec/SoftHSMv2.它是由OpenDNSSEC项目开发的软件库(https://www.opendnssec.org)其以本地文件系统上的SQLite3数据库的形式实现向虚拟HSM提供PKCS#11接口。它提供的安全性不如真正的HSM,但它允许用户在HSM不可用时尝试使用本机PKCS#11。SoftHSMv2可以配置为使用OpenSSL或Botan库来执行加密功能,但在BIND中将其用于本机PKCS#11时,需要OpenSSL。
默认情况下,SoftHSMv2配置文件为 prefix/etc/softhsm2.conf
(其中prefix
在编译时配置)。此位置可以被SOFTHSM2_CONF环境变量覆盖。在将SoftHSMv2加密存储与BIND一起使用之前,必须先安装并初始化它。
xxxxxxxxxx
$ cd SoftHSMv2
$ configure --with-crypto-backend=openssl --prefix=/opt/pkcs11/usr
$ make
$ make install
$ /opt/pkcs11/usr/bin/softhsm-util --init-token 0 --slot 0 --label softhsmv2
基于OpenSSL引擎的PKCS#11使用libp11项目中的engine_pkcs11 OpenSSL引擎。
engine_pkcs11试图将PKCS#11 API适配到OpenSSL的引擎API中。也就是说,它提供了PKCS#11模块和OpenSSL引擎API之间的网关。必须向OpenSSL注册引擎,并且必须提供应网关连接的PKCS#11模块的路径。这可以通过编辑OpenSSL配置文件、特定于引擎的控件或使用p11-kit代理模块来完成。
建议使用libp11>=0.4.12。
有关更详细的说明,包括示例,我们建议阅读: https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11
使用engine_pkcs11时,请确保将 -E pkcs11 参数传递给所有可能使用密钥的BIND二进制文件,以激活引擎支持。
尽管OpenSSL 3支持Engine API的兼容性,但由于OpenSSL和libp11中存在错误,因此不建议使用它。
无法通过engine_pkcs11生成新密钥,因此不建议在 dnssec-policy
设置中使用它。但是,可以将以前生成的密钥放在 key-directory
中,并在启动密钥滚动时让密钥管理器选择这些密钥。
配置engine_pkcs11的规范文档在libp11/README.md文件中,但为了方便用户,这里包含了一个示例工作配置:
在我们的示例中,我们使用了一个由名为OpenSSL_CONF的环境变量驱动的OpenSSL配置的自定义副本。首先,复制全局OpenSSL配置(通常在 etc/ssl/openssl.conf
中找到),并将其自定义为使用engine_pkcs11。
xxxxxxxxxx
cp /etc/ssl/openssl.cnf /opt/bind9/etc/openssl.cnf
然后,导出环境变量:
xxxxxxxxxx
export OPENSSL_CONF=/opt/bind9/etc/openssl.cnf
然后在定义任何部分(方括号内)之前,在文件顶部添加以下行:
xxxxxxxxxx
openssl_conf = openssl_init
确保文件中没有其他“openssl_conf=…”行。
在文件底部添加以下行:
x[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = <PATHTO>/pkcs11.so
MODULE_PATH = <FULL_PATH_TO_HSM_MODULE>
# if automatic logging to the token is needed, PIN can be specified as below
#PIN = 1234
init = 0
当使用基于OpenSSL引擎的PKCS#11时,可以使用 -E <Engine>
命令行选项在 named
和所有BIND dnssec-*
工具中指定OpenSSL要使用的“engine”。此引擎名称与上一节中创建的 openssl.cnf
中的 engine_id
匹配。
区域签名照常开始,只有一个小区别:我们需要使用 -E
命令行选项提供OpenSSL引擎的名称。
xxxxxxxxxx
dnssec-signzone -E pkcs11 -S -o example.net example.net
基于OpenSSL提供程序的PKCS#11使用pkcs11提供程序项目。
pkcs11-provider试图将PKCS#11 API适配到OpenSSL的provider API中;也就是说,它提供了PKCS#11模块和OpenSSL Provider API之间的网关。该引擎必须在OpenSSL中注册,并且必须提供PKCS#11模块网关的路径。这可以通过编辑OpenSSL配置文件、特定于引擎的控件或使用p11-kit代理模块来完成。
必须使用2023年10月2日或以后的pkcs11提供程序git commit 2e8c26b4157fd21422c66f0b4d7b26cf8c320570。
内置了对pkcs11-provider的BIND支持;对于pkcs11-provider,不应使用上面解释的 -E
命令行选项。
配置pkcs11-provider的规范文档在provider-pkcs11.7手册页中,但为了方便起见,这里提供了一个工作配置的副本:
在这个例子中,我们使用了一个由名为OpenSSL-CONF的环境变量驱动的OpenSSL配置的自定义副本。首先,复制全局OpenSSL配置(通常在 etc/ssl/openssl.conf
中找到),并将其自定义为使用pkcs11-provider。
xxxxxxxxxx
cp /etc/ssl/openssl.cnf /opt/bind9/etc/openssl.cnf
接下来,导出环境变量:
xxxxxxxxxx
export OPENSSL_CONF=/opt/bind9/etc/openssl.cnf
然后在定义任何部分(方括号内)之前,在文件顶部添加以下行:
xxxxxxxxxx
openssl_conf = openssl_init
确保文件中没有其他“openssl_conf=…”行。
在文件底部添加以下行:
xxxxxxxxxx
[openssl_init]
providers = provider_init
[provider_init]
default = default_init
pkcs11 = pkcs11_init
[default_init]
activate = 1
[pkcs11_init]
module = <PATHTO>/pkcs11.so
pkcs11-module-path = <FULL_PATH_TO_HSM_MODULE>
# bind uses the digest+sign api. this is broken with the default load behaviour,
# but works with early load. see: https://github.com/latchset/pkcs11-provider/issues/266
pkcs11-module-load-behavior = early
# no-deinit quirk is needed if you use softhsm2
#pkcs11-module-quirks = no-deinit
# if automatic logging to the token is needed, PIN can be specified as below
# the file referenced should contain just the PIN
#pkcs11-module-token-pin = file:/etc/pki/pin.txt
activate = 1
现在可以创建和使用HSM密钥。我们假设BIND 9已经安装,无论是从包中还是从源代码中,并且工具在 $PATH
中都很容易获得。
为了生成密钥,我们将使用OpenSC套件中的 pkcs11-tool
。在基于DEB和基于RPM的发行版上,该包都称为opensc。
我们需要生成至少两个RSA密钥:
xxxxxxxxxx
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type rsa:2048 --label example.net-ksk --pin <PIN>
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type rsa:2048 --label example.net-zsk --pin <PIN>
请记住,每个密钥都应该有唯一的标签,我们将使用该标签来引用私钥。
将存储在HSM中的RSA密钥转换为BIND 9可以理解的格式。BIND 9的 dnssec-keyfromlabel
工具可以将存储在HSM中的原始密钥与 K<zone>+<alg>+<id>
文件链接起来。
如果使用OpenSSL引擎和算法( RSASHA256
),则必须提供OpenSSL引擎名称( pkcs11
)。密钥用PKCS#11 URI方案引用;它可以包含PKCS#11令牌标签(我们假设它已初始化为bind9)、PKCS#11对象标签(使用 pkcs11-tool
生成密钥时称为“标签”)和HSM PIN。有关完整的PKCS#11 URI规范,请参阅 RFC 7512 。
转换KSK:
xxxxxxxxxx
dnssec-keyfromlabel -E pkcs11 -a RSASHA256 -l "pkcs11:token=bind9;object=example.net-ksk;pin-value=0000" -f KSK example.net
和 ZSK:
xxxxxxxxxx
dnssec-keyfromlabel -E pkcs11 -a RSASHA256 -l "pkcs11:token=bind9;object=example.net-zsk;pin-value=0000" example.net
注意:存储在磁盘上的PIN可以通过指定 pin-source=<path_to>/<file>
来使用,例如:
xxxxxxxxxx
(umask 0700 && echo -n 0000 > /opt/bind9/etc/pin.txt)
然后在标签规范中使用:
xxxxxxxxxx
pin-source=/opt/bind9/etc/pin.txt
确认当前目录中存在一个KSK和一个ZSK:
xxxxxxxxxx
ls -l K*
输出应该如下(第二个数字将不同):
xxxxxxxxxx
Kexample.net.+008+31729.key
Kexample.net.+008+31729.private
Kexample.net.+008+42231.key
Kexample.net.+008+42231.private
关于生成ECDSA密钥的说明:在查找密钥时,libp11中存在一个错误。该函数仅比较密钥的ID,而不是标签,因此在查找密钥时,它返回第一个密钥,而不是匹配的密钥。要在创建ECDSA密钥时解决此问题,请指定一个唯一的ID:
xxxxxxxxxx
ksk=$(echo "example.net-ksk" | openssl sha1 -r | awk '{print $1}')
zsk=$(echo "example.net-zsk" | openssl sha1 -r | awk '{print $1}')
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type EC:prime256v1 --id $ksk --label example.net-ksk --pin <PIN>
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type EC:prime256v1 --id $zsk --label example.net-zsk --pin <PIN>
named
该区域也可以通过 named
自动签名。同样,如果使用OpenSSL 1.x.x和engine_pkcs11,我们需要使用 -E
命令行选项提供OpenSSL引擎的名称;使用OpenSSL 3.x.x提供程序时不需要这样做。
xxxxxxxxxx
named -E pkcs11 -c named.conf
日志应包含以下行:
xxxxxxxxxx
Fetching example.net/RSASHA256/31729 (KSK) from key repository.
DNSKEY example.net/RSASHA256/31729 (KSK) is now published
DNSKEY example.net/RSA256SHA256/31729 (KSK) is now active
Fetching example.net/RSASHA256/42231 (ZSK) from key repository.
DNSKEY example.net/RSASHA256/42231 (ZSK) is now published
DNSKEY example.net/RSA256SHA256/42231 (ZSK) is now active
对于 named
使用HSM密钥对区域进行动态重新签名,和/或对通过nsupdate插入的新记录进行签名,named
必须能够访问HSM PIN。在基于OpenSSL的PKCS#11中,这是通过将PIN放入 openssl.cnf
文件(在上述示例中为 /opt/pkcs11/usr/ssl/openssl.cnf
)来实现的。
有关在全局级别配置PIN的说明,请参阅OpenSSL扩展特定文档;这样做允许 dnssec-\*
工具在不输入PIN的情况下访问HSM。( pkcs11-\*
工具直接访问HSM,而不是通过OpenSSL,因此使用它们仍然需要PIN。)