X.509 证书的序列号

发布于 2024-08-18 02:00:48 字数 173 浏览 4 评论 0原文

我正在用java为uni类编写一个证书颁发机构,现在我不知道证书序列号的最佳选择是什么。

  • 从0到veryBigNumber的简单静态计数器
  • 一些巨大的BigInt随机数

是否有任何充分的理由选择一个而不是另一个......或者没有?

谢谢,

I am programming a Certification Authority in java for a uni class, now I don't know what's the best option for the serial number of the Certificate.

  • Simple static counter from 0 to veryBigNumber
  • some huge BigInt random number

Is there any good reason for choosing one over the other... or none of them??

thanks,

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

小伙你站住 2024-08-25 02:00:48

我建议您使用随机数,但在数据库中保留这些颁发的序列号的列表。这将允许两件事。

  1. 您永远不会重新发行相同的序列号。
  2. 您可以从证书的序列号判断它是否远程有效。

当然,#1 要求您在生成时检查已知列表,并在发生冲突时生成新的随机数,而#2 在安全性或验证方面并没有多大意义,但仍然是一个有趣的前景。

I would recommend that you use a random number, but keep a list of those issued serial numbers in a database. This will allow for two things.

  1. You will never reissue the same serial number.
  2. You can tell from a certificate's serial number if it is even remotely valid.

Of course #1 requires that you check against the known list on generation and to generate a new random number if a collision occurs, and #2 isn't much of anything in terms of security or validation but an interesting prospect never-the-less.

一袭白衣梦中忆 2024-08-25 02:00:48

从技术上讲,从 0 到 veryBigNumber 的计数器比 bigRandomNumber 更容易实现 - 因为序列号必须不同。

但是,如果您关心人们知道您颁发了多少证书,您可能不想使用简单的计数器。

Technically counter from 0 to veryBigNumber is easier to implement than bigRandomNumber - because the serial numbers MUST be different.

However - you might not want to use a simple counter if you care about people knowing how many certificates you issued.

心房敞 2024-08-25 02:00:48

这取决于您使用序列号的用途。如果您是一家小公司,并且计划为每个客户提供一张证书,那么您的序列号将显示您拥有多少客户。

除此之外,我看不出有任何理由说明序列号不应该是序列号。有些人认为使用序列号会将一些信息(下一个序列号)泄露给潜在的攻击者,但我认为这不是一个大问题。

It depends on what you are using the serial number for. If you are a small company and if you are planning on giving one certificate per customer, then your serial number will reveal how many customers you have.

Other then that i dont see any reason why the serial number shouldn't be serial. Some people argue that using serial numbers will give away some information (the next serial number) to a potential attacker but i dont think that is a big issue.

吃兔兔 2024-08-25 02:00:48

主要要求是(发行者专有名称,序列号)对在宇宙中应该是唯一的。因此,不应使用随机数,除非它太大以至于重复的概率可以忽略不计。 20 字节的随机数应该足够了。如果您不介意其他人知道您颁发了多少证书,那么一个简单的计数器就完全可以了。

最近针对 SSL 证书颁发者的攻击(由 Alex Sotirov 等人发起)利用了 MD5 的弱点,实际上通过使用计数器类型的序列号变得更加容易。随机序列号没有受到攻击。这并不意味着可预测的序列号安全性较差,只是意味着对于此应用程序,随机序列号可以帮助掩盖 MD5 的弱点。根本问题仍然是MD5。

The main requirement is that the pair (Issuer distinguished name, serial number) should be unique in the universe. Therefore you should not use a random number unless it is so large that the probability of repeat is negligible. A 20 byte random number should be more than adequate. A simple counter is perfectly fine, if you don't mind other people knowing how many certificates you have issued.

The relatively recent attacks on SSL certificate issuers (by Alex Sotirov et. al) that exploited the weakness in MD5 actually were made even easier by the use of counter-type serial numbers. Random serial numbers were not attacked. This does not mean that predictable serial numbers are bad security, it just means that for this application random serial numbers could help mask the weaknesses in MD5. The root problem was still MD5.

岁吢 2024-08-25 02:00:48

我认为如果我们检查“串行”这个词,答案是隐含的......串行、系列、进展等

I think if we examine the word Serial the answer is implicit....Serial,series, progression etc

音栖息无 2024-08-25 02:00:48

我刚才偶然遇到了这个问题,从答案中你会认为可预测的序列号并不是安全问题。我想说这是一个问题,而且随机序列号更安全。比照。火焰攻击等此处 例如,或 此处 或有关“可预测的序列号攻击。"

I happened to come across this question by chance just now, and you would think from the answers that a predictable serial number is not a security concern. I would say that it is a concern, and that random serial numbers are much safer. Cf. Flame attack et al here for example, or here or the wikipedia article on "Predictable serial number attack."

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文