相关疑难解决方法(0)

我最近通过GoDaddy请求SSL证书,并注意到此消息:

在过去,我总是生成2048位的CSR请求,但这次它让我想到也许我应该"加强它",看起来下一步将是4096位版本.

关于4096位SSL证书的信息不多 - 但显然许多人一直在使用1024位证书,直到他们绝对不得不升级,现在一些浏览器将不再支持1024位证书.

浏览器如何支持4096位证书？如果GoDaddy要求"至少"一个2048位的证书,这还够,还是应该尝试做更多的事情？如果是这样,有什么优点和缺点？

PS:GoDaddy消息中的两个链接是CSR帮助和了解更多,我发现这两个链接都没有用.

我已经创建了一个基本的JWT生成器,但需要在几个方面提供建议.我一直在使用JWT.io的指南和auth0/java-jwt库/ repo来生成令牌.

JWT正在使用2个不同的密钥进行签名.

使用RSA512算法使用4096位密钥对刷新令牌进行签名.

.sign(Algorithm.RSA512(rsaPublicKey, rsaPrivateKey));

通过RSA256算法使用1024位RSA密钥对访问令牌进行签名.

 .sign(Algorithm.RSA256(rsaPublicKey, rsaPrivateKey));

由于4096位验证过程需要更长的时间,因此我对"速度"的建议已经采用了这一点,但似乎对刷新令牌的请求较少,安全性的权衡似乎是公平的.

另一方面,访问令牌在资源服务器端点进行验证,并且它们被更频繁地发送,因此我选择了更短(256)的签名,该签名使用更快的1024位密钥进行.

我知道钥匙"几乎"不可能破坏......但建议使用钥匙旋转？

我将jks(密钥库)保存在auth服务器和资源服务器上的私有文件夹中.密钥库包含2个密钥对,一个用于刷新令牌签名/验证,另一个用于访问令牌签名/验证.

我需要刷新/形成新密钥吗？如果是这样......多久一次？建议的方法是什么？

在负载均衡器后面可以有多个auth和资源微服务实例...因此RAM生成的密钥是否为,因为它们不会在实例之间传播.

我已经看过可能有一个"密钥服务器",可以说创建新密钥并将它们附加到密钥库并将新的jks文件更新为新的密钥对...类似于:

因此,例如,每隔15秒,EC2 auth服务器和资源服务器ping密钥服务器,请求当前jks的副本(和版本检查).

有什么建议？

谢谢!