最近,我使用SQL server自签名证书启动SSL加密,然后开始思考更多的问题。
1)加密算法、认证方法
所使用的加密/散列算法似乎依赖于客户机/服务器的操作系统之间的SChannel协商。-好吧。
2)自签名证书的密钥长度。
我试过问这个
select name, pvt_key_encryption_type_desc from sys.certificates
##MS_SQLResourceSigningCertificate## NO_PRIVATE_KEY
##MS_SQLReplicationSigningCertificate## NO_PRIVATE_KEY
##MS_SQLAuthenticatorCertificate## NO_PRIVATE_KEY
##MS_AgentSigningCertificate## NO_PRIVATE_KEY
##MS_PolicySigningCertificate## NO_PRIVATE_KEY
##MS_SmoExtendedSigningCertificate## NO_PRIVATE_KEY
##MS_SchemaSigningCertificate990F36EF1B3577FE5687C7465F0A5135DE9E6834## NO_PRIVATE_KEYq1)我可以检查用于SSL加密的证书是否是MS_SQLAuthenticatorCertifcate吗?
q2) / CERT如何使用“无私钥”工作?据我所知,证书/非对称加密将涉及用于加密的公钥(在证书中提供),而证书的所有者将拥有用于解密的私钥?
为什么这里不是这样的呢?
发布于 2017-10-29 16:13:20
这是太大的评论肖恩的答案,所以让我补充一下。
q1)我可以检查用于SSL加密的证书是否是MS_SQLAuthenticatorCertifcate吗?
根据主体(数据库引擎)文档,##MS_SQLAuthenticatorCertificate##证书用于基于证书的内部登录。
至少据我所知,在实例启动过程中生成的自签名证书不会被DMV公开。编辑:此外,Sean在他的回答中提到,此证书仅驻留在Server进程内存空间中,并在Server出于安全原因关闭时被删除。
q2) / CERT如何使用“无私钥”工作?据我所知,证书/非对称加密将涉及用于加密的公钥(在证书中提供),而证书的所有者将拥有用于解密的私钥?
实际的Server自签名证书是具有公钥/私钥对的X509证书。但是,请注意,出于性能原因,TLS使用对称密钥(用于加密和解密的相同密钥)对线路上的消息进行加密/解密。此会话特定的密钥是在TLS握手期间生成的,自签名证书(或提供的证书)用于生成和保护交换的秘密,而不是加密后续消息。此Microsoft (https://technet.microsoft.com/en-us/library/dn786441(v=ws.11).aspx )描述了传输层安全( TLS )协议的工作原理,并提供了指向TLS 1.0、TLS 1.1和TLS 1.2的IETF的链接。
您可以从此扩展事件跟踪中找到有关实际协商的TLS协议和密码的更多详细信息,但这需要Server 2016 SP1或更高版本:
CREATE EVENT SESSION [tls] ON SERVER
ADD EVENT sqlsni.trace(
WHERE ([sqlserver].[equal_i_sql_ansi_string]([function_name],'Ssl::Handshake') AND [sqlserver].[like_i_sql_unicode_string]([text],N'%TLS%')))
ADD TARGET package0.event_file(SET filename=N'tls_trace')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);下面是使用来自Server 2017跟踪的自签名证书的事件文本字段的示例
SNISecurity Handshake Handshake succeeded. Protocol: TLS1.2 (1024), Cipher: AES 256 (26128), Cipher Strength: 256, Hash: SHA 384 (32781), Hash Strength: 0, PeerAddr: ::1 发布于 2020-06-15 18:34:00
我对SQL server的研究还不够深入,所以我可以准确地回答您的所有问题。那么,让我们从我所确定的开始。
你绝对是对的。每个通过TLS / SSL连接与其他各方通信的软件都需要一个与其公钥相匹配的私钥,因为SSL / TLS通过非对称RSA (或现在的EC)加密来交换实际的加密密钥。句号。
请注意,需要私钥的事实并不是因为涉及到证书这一事实。相反,不对称RSA和EC加密的原则是必须有一个私钥匹配公钥,而不管实际实现如何。
公钥和其他数据(例如计算机或组织名称、受信任的根或中间当局的标识等)通常存储在一方向另一方出示的证书中,从而声称具有某种身份。应由另一方来核实索赔是否属实,即提交证书的一方是否真的是它假装的那样。
与证书公钥匹配的私钥可能存储在意想不到的位置。
例如,我使用certreq为Server 2012生成了SSL证书(有关详细信息,请参阅这里 )。当我发布这个过程的最后命令时,就是,
certreq -new -f req.inf test.cer创建了一个证书并将其自动导入到Windows证书存储区(我后来使用SSCM为有关实例激活该证书),该证书的私钥被放入一个文件中,该文件的名称位于以下位置:
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\我绝对确信,我并不知道为SQL server的SSL / TLS身份验证创建证书的所有方法,但我再次肯定,所有方法都涉及创建私钥,并且SQL server需要此密钥来针对其他各方(客户端或(作为客户端)服务器进行身份验证)。
毕竟,基于证书的服务器身份验证的关键在于客户端检查服务器是否能够证明它拥有与服务器证书的公钥匹配的私钥。如果服务器没有该密钥,则证书不属于该服务器,并且客户端拒绝继续连接。
例如,在我的例子中,如果SQL Server不能从上面提到的机器密钥存储区读取匹配TLS证书的私钥,那么它甚至不会启动。
要将证书SSL / TLS与其他证书进行比较,我将执行以下操作:
(
启动SSCM ( Server配置管理器;如果没有安装,请通过Server安装程序将其添加到安装中--它是配置/管理工具的一部分)。在左窗格中,展开“”,并(仍然在左侧窗格中)右击"Protocols“(其中xxx是所讨论的实例)。在上下文菜单中,选择"Properties“。
这将打开一个带有多个选项卡的对话框,其中包括一个名为“证书”的选项卡。激活此选项卡并按下“查看.”按钮。这将打开通常的Windows对话框,其中显示证书的详细信息。在您的例子中,这个对话框中的选项卡"Details“非常有趣。除其他外,它包含证书的拇指指纹,这是唯一的。把指纹记下来。
在我的例子中,拇指指纹是ce8623c589bc1a4a7733cb6a5ac43824838a4415。
(
您可以这样查询其他证书:
select name, thumbprint from sys.certificates它(在我的例子中)给出了以下结果:
##MS_SQLResourceSigningCertificate## 0x6D5F2F7CA5696AC5333BABB0E4AD1E96DD99DBC7
##MS_SQLReplicationSigningCertificate## 0x5B630A36C16BB9D79982A64BC0B3B584E7485B31
##MS_SQLAuthenticatorCertificate## 0x40FCDF6DBE46A1201A7CBFB7E6421172F67EE9F7
##MS_AgentSigningCertificate## 0x62D95F0D5A702BB990BB688BAC1DAB83E6B6487F
##MS_PolicySigningCertificate## 0x8EFAD562CDCF43FFC3618BE6C8CBE11FB62C19B6
##MS_SmoExtendedSigningCertificate## 0xB36E8511BA3A33BED8A6F848E100B7DF691AAD8B
##MS_SchemaSigningCertificateFBBED91EB3ECA494D27028E6F5921426EBFA28A8## 0xC60791200612C0F13D047F2250BCA93865646097现在,将这些指纹与步骤a中获得的SSL / TLS证书的指纹进行比较)。这清楚地表明,SSL / TLS证书与MS_SQLAuthenticatorCertificate不完全相同。
顺便说一句,我不知道您的示例中的pvt_key_encryption_type_desc实际包含或意味着什么,以及这些##MS_...证书用于什么目的。但是,Server最终需要知道证书的私钥,该证书用于针对客户端(或其他坚持要求客户端提交证书的服务器)进行身份验证。
因此,我怀疑您误解了NO_PRIVATE_KEY的实际含义(我没有机会误解它,因为我以前从未见过它:-)。
我可能不应该写更多的东西,因为下面的只是猜测,所以不要太严肃。但是,有一些证书格式直接将私钥作为证书本身的一部分。也许NO_PRIVATE_KEY意味着相应的证书不直接包含私钥;在这种情况下,它存储在其他地方,至少对于Server实际用于身份验证的证书是这样的。
https://dba.stackexchange.com/questions/189594
复制相似问题