分类
知识中心

证书生命周期

那些发送电子邮件或运行网站的人的真实性每天都受到质疑,因为攻击者会假装成他们不会破坏互联网用户的敏感数据。证明这种真实性的最简单方法是使用数字证书。数字证书利用只有密钥对的创建者才能拥有的密钥对,从而证明他们是他们所说的人。证书还由称为证书颁发机构或 CA 的受信任颁发机构创建和签名。CA利用信任链,回到原始CA,该CA保持离线和安全,以确保它不会受到损害。

但是,证书不仅仅是创建并提供给用户的。它们遵循一个重要的生命周期,该生命周期用于保护和续订证书,因此可以持续使用它们,而不必担心攻击者窃取它们并掩盖自己是证书的所有者。对证书颁发机构创建的证书的信任始于保证其证书生命周期得到良好管理并且不受损害。证书生命周期的实现非常重要,因为它等同于颁发证书的用户的身份。

分类
知识中心

什么是证书签名请求文件(CSR)?

证书签名请求 (CSR) 是用户申请证书(如 SSL/TLS 证书)时转发给证书颁发机构 (CA) 的编码文本块。CSR 是在将安装证书的服务器上创建的。CSR 包括域名、组织名称、位置和国家/地区等信息。该请求还包含公钥,该公钥将与生成的证书相关联,并且同一服务器还生成私钥。在开发证书时,CA只会使用公钥,私钥应该保存并保密,因为私钥是公钥的密钥对,如果我们丢失私钥,证书将不起作用。

什么是证书签名请求文件(CSR)?

CSR文件包括下面信息:

  • 域名:服务器的完全限定域名 (FQDN),如 www.ert7.com。
  • 组织名称:组织的法定名称,例如“北京天威诚信电子商务服务有限公司”。
  • 组织单位:组织的部门,如 IT 部门。
  • 城市/地点:组织所在的城市,例如北京/青岛。
  • 州/县/地区:如北京/山东
  • 国家:如中国
  • 电子邮件地址:用于与组织联系的电子邮件地址,例如 ssl@ert7.com
  • 公钥:将与证书关联的公钥。
分类
知识中心

什么是证书信任链?

证书信任链是指从您拥有的证书一直到根 CA 的证书列表。组织可能信任的根 CA 只有少数几个。如果我们需要信任证书,我们还需要信任该证书的颁发者和该证书的颁发者,依此类推。这种情况一直持续到我们找到根 CA,其中检查其证书并确定它是否受信任。如果根 CA 具有有效且受信任的证书,则所有中间 CA 和服务器的证书都将自动被视为有效。

分类
公司新闻

代码签名证书私钥保护升级措施延期通知

CA/B论坛最新消息,原定于2022年11月15日起执行的代码签名证书私钥保护升级措施,将延期至2023年6月1日,期间用户可在天威诚信继续按照现有规则申请和使用代码签名证书

此次变更旨在加强对代码签名证书私钥的保护。按CA/B论坛规定,2023年6月1日以后,普通(OV)代码签名证书密钥对必须在达到FIPS 140-2 Level2 或EAL4+通用标准以及更高标准的硬件加密模块中生成并存储。

具体变更方式如下:

变更前:对于普通代码签名证书,天威诚信获取到用户的CSR后,将其提交至CA进行数字签名后生成证书,再通过邮件的方式将证书发送给用户,无需硬件介质。

变更后:自2023年6月1日起,购买普通代码签名证书将和EV代码签名证书一样,证书由天威诚信签发并存储在预配置的USB Key上,再通过邮寄的方式将USB Key寄送给用户。

需要注意的是,此次升级只针对普通(OV)代码签名证书。EV代码签名证书及2023年6月1日前签发的普通代码签名证书不受影响。

同时,已经使用代码签名证书或EV代码签名证书签名且加盖时间戳的软件不受影响并长期有效。

代码签名证书是提供软件开发者可以进行代码软件数字签名的认证服务。通过对代码的数字签名可以消除软件在Windows系统被下载安装时弹出的“不明开发商”安全警告,保证代码完整性和不被恶意篡改,使软件开发者信息对下载用户公开可见,从而建立良好的软件品牌信誉度。

可以预见的是,代码签名私钥存储新规开始执行后,OV代码签名证书将从“软证书”变为“硬证书”,更有助于降低私钥泄漏的可能性。

为避免此次代码签名证书私钥保护升级带来的不便,天威诚信提醒有需要的用户提前做好计划和工作安排,天威诚信可为用户提供各主流厂商的代码签名证书以及相应的USBkey寄发和更换服务。

分类
知识中心

代码签名的弱点

代码签名也有几个弱点,包括:
  • 对在代码签名过程开始时创建的私钥管理不当可能会导致所发送软件的不安全。如果合法的私钥被盗,则攻击者可以使用私钥对其恶意软件进行编码,这将告诉用户该软件可以安全使用,即使它不是。
  • 威胁参与者可以获得受信任的证书,但阻止大多数攻击者的是需要提供标识信息才能获得证书。如果使用合法证书分发恶意软件,则可以识别并阻止开发人员。
  • 如果用户允许安装软件,即使操作系统说它没有代码签名,那么代码签名将变得毫无用处。
为了防止这些弱点,应该遵循一些最佳实践。
  • 为了保护加密密钥,应使用硬件安全模块或 HSM。HSM 是一种高度受信任的专用物理设备。它是一种网络计算机,执行所有主要的加密操作,包括加密,解密,身份验证,密钥管理,密钥交换等。它们具有防篡改功能,并使用极其安全的加密操作。
  • 与 HSM 一起,最小特权原则应与密钥一起使用,以确保只有需要密钥的用户才能访问它。
  • 最后,在进行代码签名时应始终谨慎使用。仅下载并安装由受信任的 CA 签名的代码的软件。
分类
知识中心

代码签名如何工作?

代码签名有几个步骤,从创建唯一密钥对开始。创建的密钥对是公钥-私钥对,因为代码签名使用公钥加密。创建密钥对后,公钥将发送到受信任的证书颁发机构或 CA,该证书颁发机构通过向软件开发人员返回公钥以及经过数字签名的代码签名证书来验证密钥是否属于所有者。CA 是高度受信任的实体,负责签名和生成数字证书。CA 返回的带有附加公钥的证书确认了开发人员及其创建的任何软件的可信度。

现在已返回公钥和数字代码签名证书,软件的代码将通过哈希函数运行。哈希函数是一个单向函数,它将放入函数中的文本转换为无法反转的值的任意混合。这提供了一个值,用于与将数据发送给使用者时进行比较。然后,输出或摘要由私钥加密。私钥用于加密而不是公钥的原因是,开发人员希望任何人都能够读取消息,但没有人能够篡改它。摘要、代码签名证书和哈希函数现在被组合成一个签名块,并放入软件中,然后发送给消费者。

收到软件后,消费者的计算机首先检查代码签名证书的真实性。一旦确认了真实性,摘要就会使用最初创建的密钥对的公钥进行解密。然后,在软件的代码上使用哈希函数,并将生成的摘要与开发人员发送的摘要进行比较。如果摘要匹配,则软件可以安全安装。

分类
知识中心

weblogic + jdk1.6 报错

weblogic + jdk1.6 报错Unsupported OID in the AlgorithmIdentifier object

I am getting the following error enabling SSL, when I use the jkd 1.6.0_13 and WebLogic Server 10.3

Aug 21, 2009 11:30:16 AM GMT+00:00> <Emergency> <Security> <BEA-090034> <Not listening for SSL, java.io.IOException: PKIX: Unsupported OID in the AlgorithmIdentifier object: 1.2.840.113549.1.1.11.>

<Aug 21, 2009 11:30:16 AM GMT+00:00> <Error> <WebLogicServer> <BEA-000297> <Inconsistent security configuration, java.security.cert.CertificateParsingException: PKIX: Unsupported OID in the AlgorithmIdentifier object: 1.2.840.113549.1.1.11>

Resolution:

To output the keys affected from {JAVA_HOME}\bin (Windows):

keytool -list -v -keystore ..\lib\security\cacerts -storepass changeit > list.txt

I ended up having to delete the following keys:

keytool -delete -keystore ..\lib\security\cacerts -alias ttelesecglobalrootclass2ca -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias ttelesecglobalrootclass3ca -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias keynectisrootca -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias thawteprimaryrootcag3 -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias globalsignr3ca -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias secomscrootca2 -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias verisignuniversalrootca -storepass changeit

keytool -delete -keystore ..\lib\security\cacerts -alias geotrustprimarycag3 -storepass changeit

Referrence:

http://forums.oracle.com/forums/thread.jspa?threadID=947219

问题原因:

查询了网上,得到原因是由于AIX上使用了IBM的JDK,jre/lib/security/cacerts中某些ca根证书的签名算法方式不被weblogic所支持,也可以说是JDK和weblogic不配套。如果在Linux或Windows下的weblogic版本,由于自身就带有jdk,故是配套的,所以不存在签名算法的问题。因此也不能说一定是IBM的JDK问题,JDK版本和Weblogic不配套也会出现此类问题。

 

解决方法:

删除cacerts下不被weblogic支持的签名算法的证书。

查询OID为1.2.840.113549.1.1.11的是sha256WithRSA算法,故删除sha256WithRSA算法的ca证书。

 

keytool -delete -keystore ../lib/security/cacerts -alias ttelesecglobalrootclass2ca -storepass changeit

keytool -delete -keystore ../lib/security/cacerts -alias ttelesecglobalrootclass3ca -storepass changeit

keytool -delete -keystore ../lib/security/cacerts -alias keynectisrootca -storepass changeit