Intel AMT自从3.0版本就开始支持零接触配置（ZTC， Zero Touch Configuration，官方现在的命名是 Remote Configuration）方式，即通过AMT固件中内置的根证书列表，来匹配配置服务器端使用的证书，并通过OTP (One Time Password) 和指定的域名来进一步认证双方的身份。配置服务器端在收到AMT发送过来的Hello消息后，匹配AMT内置的根证书列表的Hash值，然后使用由配置的 Hash值的根证书签发的证书作为服务器端证书与AMT进行TLS通信；这个时候，AMT会生成一个自签名证书由于TLS的交互式认证。在使用Intel AMT SDK 5.0提供的ConfigurationServer例子来测试这个功能时，发现了如下错误："SSL_ERROR_SSL error: 14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error"， 见下图。
看起来是配置服务器端与AMT客户端尝试建立TLS连接时失败。根据以前的经验，仔细来回检查了证书好几遍，根证书对着呢，需要Full Chain的本地使用证书也应该没问题啊，奇怪了。
百思不得其解的时候，通过与他人讨论，觉得可能还是证书的CN名称的问题，AMT匹配证书CN名称时候没有通过。通过几次实验后，终于找到原因了，原来在 ZTC（也就是PKI Provisioning）模式下，AMT会主动去匹配配置服务器端使用的证书的CN名称的域名是否与当前DHCP服务器分配的域名一致，我们只需要在生 成证书的时候，将证书CN使用的名称的后缀设置成与当前网络环境域名一致即可。
关于域名匹配这点，Intel AMT在ZTC模式中还可以做到强制检查FQDN Subfix，即可以通过MEBX中设置需要强制匹配的域名后缀。看来如果没有设置，Intel AMT是和默认DHCP的默认域名做匹配。
百思不得其解的时候，通过与他人讨论，觉得可能还是证书的CN名称的问题，AMT匹配证书CN名称时候没有通过。通过几次实验后，终于找到原因了，原来在 ZTC（也就是PKI Provisioning）模式下，AMT会主动去匹配配置服务器端使用的证书的CN名称的域名是否与当前DHCP服务器分配的域名一致，我们只需要在生 成证书的时候，将证书CN使用的名称的后缀设置成与当前网络环境域名一致即可。
关于域名匹配这点，Intel AMT在ZTC模式中还可以做到强制检查FQDN Subfix，即可以通过MEBX中设置需要强制匹配的域名后缀。看来如果没有设置，Intel AMT是和默认DHCP的默认域名做匹配。
本文转自Intel_ISN 51CTO博客，原文链接：http://blog.51cto.com/intelisn/130456，如需转载请自行联系原作者
