On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz wrote:
> I have skimmed through a few RFCs following today's postings and a few web
> sites. It would seem to me that I should:
>
> Remove commonName and emailAddress completely from the cnf file. They no
> longer belong in any cert, root or inte
I have skimmed through a few RFCs following today's postings and a few
web sites. It would seem to me that I should:
Remove commonName and emailAddress completely from the cnf file. They no
longer belong in any cert, root or intermediate CA certs, server or user
certs.
For servers include s
Certificate serial numbers must be unique. They need not be sequential or
increasing. (Mozilla's NSS will complain and refuse to work if there are
duplicate serial numbers.)
I tend not to re-use keys, so I've found that putting 20 bytes (while
clearing the high bit) of a digest of the SubjectPub
On 16-08-17 15:24, Tom Browder wrote:
[...]
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given
> that the certs are only used for us. I'm not even sure I'll ever revoke
> any cert (they were issued to ex
On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote:
There’s no such requirement. It MUST be at most 20 octets long.
>
>> - Serial numbers contain cryptographically strong random bits,
currently at
>> least 64 random bits, though it is best if the entire serial number
l
>So we will have to wait for the next release or build our own...
Yes, as always. Features go into the next release; fixes into existing ones.
>Will there be some option to control the behavior?
Yes, like –rand_serial or some such in the ca and x509 commands.
--
openssl-users
On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote:
There’s no such requirement. It MUST be at most 20 octets long.
>
>> - Serial numbers contain cryptographically strong random bits,
currently at
>> least 64 random bits, though it is best if the entire serial number
l
> There’s no such requirement. It MUST be at most 20 octets long.
>
>> - Serial numbers contain cryptographically strong random bits, currently
at
>> least 64 random bits, though it is best if the entire serial number looks
>> random from the outside. This is not implemented by th
>> Another requirement is that a TLS server certificate shall have its identity
>> (FQDN) in the SAN extension. Use of the commonName attribute has been
>> deprecated long ago.
> Where is this documented ?
Might be of interest :
https://stackoverflow.com/questions/5935369/ssl-how-do-common-nam
On 08/16/2017 11:58 AM, Erwann Abalea via openssl-users wrote:
Bonjour,
Le 16 août 2017 à 16:51, Jakob Bohm a écrit :
On 16/08/2017 16:32, Tom Browder wrote:
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users mailto:openssl-users@openssl.org>> wrote:
➢ So, in summary, do I nee
Bonjour,
> Le 16 août 2017 à 16:51, Jakob Bohm a écrit :
>
> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users
>> mailto:openssl-users@openssl.org>> wrote:
>>
>>➢ So, in summary, do I need to ensure cert serial numbers are
>>unique fo
On 16/08/2017 19:54, Robert Moskowitz wrote:
On 08/16/2017 01:12 PM, Viktor Dukhovni wrote:
On Aug 16, 2017, at 12:52 PM, Robert Moskowitz
wrote:
Which is also a problem in openssl. You have to put the SAN into
the cnf file. There are a number of hacks to do this from the
command line.
On 08/16/2017 01:12 PM, Viktor Dukhovni wrote:
On Aug 16, 2017, at 12:52 PM, Robert Moskowitz wrote:
Which is also a problem in openssl. You have to put the SAN into the cnf file.
There are a number of hacks to do this from the command line.
Yep. For an approach that uses "bash" in-line
> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz wrote:
>
> Which is also a problem in openssl. You have to put the SAN into the cnf
> file. There are a number of hacks to do this from the command line.
Yep. For an approach that uses "bash" in-line files see:
https://github.com/openssl/
On 08/16/2017 10:51 AM, Jakob Bohm wrote:
On 16/08/2017 16:32, Tom Browder wrote:
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users
mailto:openssl-users@openssl.org>> wrote:
➢ So, in summary, do I need to ensure cert serial numbers are
unique for my CA?
Why would you no
Replying personally:
I'm a nobody, and you have no reason to know me - but wanted to thank you for
the input you give here.
You're nearly always quite thoughtful, careful in what you say, respectful, and
give such [IMO] good insightful feedback and information to people looking for
help. I fol
On 16/08/2017 16:32, Tom Browder wrote:
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users
mailto:openssl-users@openssl.org>> wrote:
➢ So, in summary, do I need to ensure cert serial numbers are
unique for my CA?
Why would you not? The specifications require it, but those
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:
> ➢ So, in summary, do I need to ensure cert serial numbers are unique for
> my CA?
>
> Why would you not? The specifications require it, but those
> specifications are for interoperability. If nobody i
On Wed, Aug 16, 2017 at 08:32 Michael Ströder wrote:
> Tom Browder wrote:
...
> > So, in summary, do I need to ensure cert serial numbers are unique for my
> > CA?
>
> Yes, serial numbers should be unique per issuer-DN because the 2-tuple
> (issuer-DN, cert serial no.) is expected to be unique
➢ So, in summary, do I need to ensure cert serial numbers are unique for my CA?
Why would you not? The specifications require it, but those specifications are
for interoperability. If nobody is ever going to see your certs, then who cares
what’s in them?
--
openssl-users mailing list
To uns
Tom Browder wrote:
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given that
> the certs are only used for us. I'm not even sure I'll ever revoke any
> cert (they were issued to expire sometime in 2030).
>
Many years ago I started a CA for one group I manage for a private website,
and now I want to update members' client certs for the stricter
requirements for browsers.
My original cert generation was entirely automated including the following:
+ CN for each is an e-mail address for the member
+ t
22 matches
Mail list logo
