Re: [openssl-users] Using set_serial to control serial number size directly

[Jakob Bohm]

On 21/08/2017 16:22, Robert Moskowitz wrote:



On 08/21/2017 10:03 AM, Salz, Rich wrote:

If the root is going to be trusted, make its serial number be one. ☺
Otherwise use eight bytes of random as the serial number, if you 
follow CABF guidelines.


Kind of where my thinking is going.  But once I make it '1', it might 
as well be 1 byte rand!  :)


Well 1 - 127 random...

But no need to make it 20 octets.  Just leave it at 8. And yes, I can 
see some jump on the 'save' 7 bytes bandwagon.

Note that while the random bits in the serial number are technically
there to defend against attacks on the issuing CA if that CA uses an
old/outdated algorithm, the real issue is retaining compatibility
with Browsers that blindly assume that certificates are created
according to the contractual requirements applied to public CAs such
as DigiCert.

One of those is 20 bytes max (after DER encoding, thus 159 bits max).

Another is at least 64 fresh random bits in each serial number
generated by the CA.

Another may or may not be 20 bytes min (before DER encoding, thus
153 bits min).

Also why I have to work out BER to compare that sizing to DER. Trying 
to do that today. 

BER is never shorter than DER.

However for internal processing in memory-restricted devices, it may be
possible/easy to save space by using a simplified encoding internally,
and then convert to DER on the fly when talking to standard software
(such as Web Browsers) externally.  This will ultimately be a trade off
between code size (to do the conversion) and data size (to store the
certificate).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

I had a frustrating day.  I looked at the documentation at:

https://www.openssl.org/docs/man1.0.2/apps/x509.html

My Fedora24 reports that I am at version 1.0.2k

I made the following comand:

openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
 -in $dir/csr/intermediate.csr.$format -outform $format -out 
$dir/certs/intermediate.cert.$format\

-CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
 -CA $cadir/certs/ca.cert.$format

Where format=der and got that der is an invalid option.  Plus the 'help' 
reported:


Note that -CAkeyform is invalid and that -CAkey can only be PEM.

Even when I used my pem CA key, I still got errors.  -config is not an 
option, where does this command get the config file from? -extensions 
says it looks to the config file for that label!


SHA256 is not listed as a valid hash.

usage: x509 args
 -inform arg - input format - default PEM (one of DER, NET or PEM)
 -outform arg- output format - default PEM (one of DER, NET or PEM)
 -keyform arg- private key format - default PEM
 -CAform arg - CA format - default PEM
 -CAkeyform arg  - CA key format - default PEM
 -in arg - input file - default stdin
 -out arg- output file - default stdout
 -passin arg - private key password source
 -serial - print serial number value
 -subject_hash   - print subject hash value
 -subject_hash_old   - print old-style (MD5) subject hash value
 -issuer_hash- print issuer hash value
 -issuer_hash_old- print old-style (MD5) issuer hash value
 -hash   - synonym for -subject_hash
 -subject- print subject DN
 -issuer - print issuer DN
 -email  - print email address(es)
 -startdate  - notBefore field
 -enddate- notAfter field
 -purpose- print out certificate purposes
 -dates  - both Before and After dates
 -modulus- print the RSA key modulus
 -pubkey - output the public key
 -fingerprint- print the certificate fingerprint
 -alias  - output certificate alias
 -noout  - no certificate output
 -ocspid - print OCSP hash values for the subject name and 
public key

 -ocsp_uri   - print OCSP Responder URL(s)
 -trustout   - output a "trusted" certificate
 -clrtrust   - clear all trusted purposes
 -clrreject  - clear all rejected purposes
 -addtrust arg   - trust certificate for a given purpose
 -addreject arg  - reject certificate for a given purpose
 -setalias arg   - set certificate alias
 -days arg   - How long till expiry of a signed certificate - def 
30 days

 -checkend arg   - check whether the cert expires in the next arg seconds
   exit 1 if so, 0 if not
 -signkey arg- self sign cert with arg
 -x509toreq  - output a certification request object
 -req- input is a certificate request, sign and output.
 -CA arg - set the CA certificate, must be PEM format.
 -CAkey arg  - set the CA key, must be PEM format
   missing, it is assumed to be in the CA file.
 -CAcreateserial - create serial number file if it does not exist
 -CAserial arg   - serial file
 -set_serial - serial number to use
 -text   - print the certificate in text form
 -C  - print out C code forms
 - - digest to use, see openssl dgst -h output for list
 -extfile- configuration file with X509V3 extensions to add
 -extensions - section from config file with X509V3 extensions to add
 -clrext - delete extensions before signing and input certificate
 -nameopt arg- various certificate name options
 -engine e   - use engine e, possibly a hardware device.
 -certopt arg- various certificate text options
 -checkhost host - check certificate matches "host"
 -checkemail email - check certificate matches "email"
 -checkip ipaddr - check certificate matches "ipaddr"


So it looks like for now, I cannot make a guide that easily supports DER 
or PEM.  DER really seems to be an issue how to make.


My searching has come up pretty empty.  No instructions out there.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openssl ca can only create PEM certs

[Robert Moskowitz]

-outform in the following is invalid:

openssl ca -outform $format -config $cadir/openssl-root.cnf -extensions 
v3_intermediate_ca\

  -keyform $format -days 3650 -notext -md sha256 \
  -in $dir/csr/intermediate.csr.$format -out 
$dir/certs/intermediate.cert.$format


where format=der

Looks like can can convert the pem to der with:

openssl x509 -outform der -in certificate.pem -out certificate.der

But, I am going to have to figure out how to do the same sort of process 
using 'openssl x509'.


I think one of the args is -CA, and  then I can use -set_serial and not 
need the serial file...


Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem with DER private key file into openssl ca

[Robert Moskowitz]

On 08/21/2017 01:41 PM, Jeffrey Walton wrote:

openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial
0x$(openssl rand -hex $sn)\
   -inform $format -key private/ca.key.$format -subj "$DN"\
   -new -x509 -days 7300 -sha256 -extensions v3_ca -out
certs/ca.cert.$format

unable to load Private Key
140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start
line:pem_lib.c:707:Expecting: ANY PRIVATE KEY

How do I tell it that the private key is DER?

-inform is used to specify the encoding. You can find the man pages at
https://www.openssl.org/docs/man1.0.2/apps/. You want the req.html.


And the proper argument is:

-keyform

Thanks

This is so much fun.  Sigh.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem with DER private key file into openssl ca

[Jeffrey Walton]

> openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial
> 0x$(openssl rand -hex $sn)\
>   -inform $format -key private/ca.key.$format -subj "$DN"\
>   -new -x509 -days 7300 -sha256 -extensions v3_ca -out
> certs/ca.cert.$format
>
> unable to load Private Key
> 140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>
> How do I tell it that the private key is DER?

-inform is used to specify the encoding. You can find the man pages at
https://www.openssl.org/docs/man1.0.2/apps/. You want the req.html.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problem with DER private key file into openssl ca

[Robert Moskowitz]

format=der

openssl pkey -inform $format -in private/ca.key.$format -text -noout

Private-Key: (256 bit)
priv:
48:b3:4e:c5:0a:0c:af:78:b9:a2:d4:b8:7e:18:78:
f2:39:9c:77:51:a3:1c:6f:df:31:20:e3:e4:9a:52:
3d:06
pub:
04:ce:ff:5d:d4:c7:b6:9c:c2:31:d9:38:fe:2b:9c:
70:3a:fd:22:6d:97:d0:10:23:b3:57:6b:a9:51:e8:
ce:db:16:0e:6e:8f:31:ca:6c:fe:09:69:25:be:2e:
bf:fd:cc:ab:22:91:c8:db:f2:68:13:5a:57:03:5f:
b2:ab:f6:ec:9d
ASN1 OID: prime256v1
NIST CURVE: P-256

openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial 
0x$(openssl rand -hex $sn)\

  -inform $format -key private/ca.key.$format -subj "$DN"\
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.$format


unable to load Private Key
140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:pem_lib.c:707:Expecting: ANY PRIVATE KEY


How do I tell it that the private key is DER?

Bob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

[Viktor Dukhovni]

On Mon, Aug 21, 2017 at 03:43:05PM +, Salz, Rich via openssl-users wrote:

> ➢ But if I use format=der I do not get prompted for the password.
>
> DER does not support encryption.  The bug is that the command does not tell 
> you this.

There is at least one standard encryption-capable ASN.1 private
key format, namely PKCS#8, and therefore a DER encoding thereof.
However, the (gen)pkey command does not support direct input or
output of encrypted PKCS8 in DER form.  This is a reflection of
the underlying API.

 Note, takes no password argument:
d2i_PrivateKey(3)   OpenSSL  d2i_PrivateKey(3)

NAME
   d2i_Private_key, d2i_AutoPrivateKey, i2d_PrivateKey - decode and encode
   functions for reading and saving EVP_PKEY structures.

SYNOPSIS
#include 

EVP_PKEY *d2i_PrivateKey(int type, EVP_PKEY **a, const unsigned char 
**pp,
 long length);
EVP_PKEY *d2i_AutoPrivateKey(EVP_PKEY **a, const unsigned char **pp,
 long length);

...

NOTES
   All these functions use DER format and unencrypted keys. Applications
   wishing to encrypt or decrypt private keys should use other functions
   such as d2i_PKC8PrivateKey() instead.

-- Note, takes a password argument:
d2i_PKCS8PrivateKey(3)  OpenSSL 
d2i_PKCS8PrivateKey(3)

NAME
   d2i_PKCS8PrivateKey_bio, d2i_PKCS8PrivateKey_fp,
   i2d_PKCS8PrivateKey_bio, i2d_PKCS8PrivateKey_fp,
   i2d_PKCS8PrivateKey_nid_bio, i2d_PKCS8PrivateKey_nid_fp - PKCS#8 format
   private key functions

SYNOPSIS
#include 

EVP_PKEY *d2i_PKCS8PrivateKey_bio(BIO *bp, EVP_PKEY **x, 
pem_password_cb *cb, void *u);
EVP_PKEY *d2i_PKCS8PrivateKey_fp(FILE *fp, EVP_PKEY **x, 
pem_password_cb *cb, void *u);

So, while you can indirectly generate encrypted DER private keys:

$ openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 |
openssl pkcs8 -topk8 -v2 aes-128-cbc -outform DER -out key.der
...+++
+++
Enter Encryption Password:
Verifying - Enter Encryption Password:

$ openssl asn1parse -in key.der -inform DER
openssl asn1parse -inform DER
0:d=0  hl=4 l=1311 cons: SEQUENCE
4:d=1  hl=2 l=  73 cons: SEQUENCE
6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
   17:d=2  hl=2 l=  60 cons: SEQUENCE
   19:d=3  hl=2 l=  27 cons: SEQUENCE
   21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
   32:d=4  hl=2 l=  14 cons: SEQUENCE
   34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:9C914F36B0FDC2D0
   44:d=5  hl=2 l=   2 prim: INTEGER   :0800
   48:d=3  hl=2 l=  29 cons: SEQUENCE
   50:d=4  hl=2 l=   9 prim: OBJECT:aes-128-cbc
   61:d=4  hl=2 l=  16 prim: OCTET STRING  [HEX DUMP]:...iv...
   79:d=1  hl=4 l=1232 prim: OCTET STRING  [HEX DUMP]:...ciphertext...

they can't directly be used with any of the OpenSSL "-inkey" or
similar options, as those don't assume PKCS8 and typically use:

EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x,
  pem_password_cb *cb, void *u);

EVP_PKEY *PEM_read_PrivateKey(FILE *fp, EVP_PKEY **x,
  pem_password_cb *cb, void *u);

the DER counterparts lack the password argument and can't read
encrypted keys.  So encrypted PKCS#8 is fine for moving keys
between organizations, systems or people, but for data at rest,
if you want encrypted keys, you'll need PEM.

Use a strong passphrase, as the PBKDF for PEM encryption is
weak.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Erwann Abalea via openssl-users]

My proposal.

Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a 
block cipher operating on blocks of k bits, and operate this block cipher in 
CTR mode, with a proper secret key and secret starting counter. That way, no 
collision detection is necessary, you’ll be able to generate 2^(k/2) unique k 
bits longs serial numbers (in fact, you can generate 2^k unique serial numbers, 
but after 2^(k/2) you lose some security guarantees).

With 3DES, k=64, and with AES, k=128.
Since you need to make a tradeoff between security and size, you can play with 
lightweight block ciphers such as Simon, Speck, or find some tweakable 
lightweight block cipher, maybe from the ECRYPT portfolio (it’s down at this 
moment).

Again, the 64bits coming from a CSPRNG is for public CAs only, and the 
uniqueness of a serial number is a dirty hack to be able to use a non 
collision-resistant hash function a little longer. If you’re confident the hash 
function used for signature is collision resistant (for example a member of the 
SHA2 or SHA3 family), and you have a purely private CA, don’t bother will all 
this, the only hard requirement is the unicity of the tuple {CA name, serial 
number}.

Cordialement,
Erwann Abalea

> Le 21 août 2017 à 15:44, Robert Moskowitz  a écrit :
> 
> 
> 
> On 08/21/2017 09:36 AM, Salz, Rich wrote:
>> ➢ Thus how large does this random number have
>> 
>> It’s also to protect against predicting serial numbers and being able to 
>> leverage that.  It’s not just (nor really mainly) the MD5 digest attacks.  
>> According to CABForum, you need 8 octets.  No reason not to use more if you 
>> can.
> 
> Sure there is.  On constrained systems with constrained communication links.  
> Every byte counts.  My real thrust on this is for IoT.  To get IoT developers 
> to build around certs and know their products work with them instead of, well 
> we will get to it eventually.
> 
> When I work with 802.15.4 communications with a 128 byte MTU, there is 
> considerable debate over every byte sent.  When you tell an IoT chip maker 
> that they have to go from 32KB memory to 100MB, they walk out of the room.
> 
> Oh, I want DOTS and I2NSF developers to be working with certs from the get 
> go, instead waiting for deployments and getting 'production' certs and THEN 
> discovering what works and what does not.  But IoT is in many ways more of a 
> challenge.
> 
> So yes, size matters.
> 
>> 
>> 
>> ➢ page was talking about in conjunction with the -CA option. With 'openssl
>> ca' use of the serial file is mandatory according to the man page.
>> There are no command line options for it.
>> 
>> Fixed in master and will be part of the next releases; the –rand_serial flag.
>> 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

[Robert Moskowitz]

On 08/21/2017 11:52 AM, Salz, Rich wrote:

➢ OK.  And why does DER not support encryption

Because it is not defined.  If you want to encrypt keys, you need to use PKCS12 
which might be too much for your application.

If a device has secure storage, it does not need to encrypt its private 
key.  It all depends on the architecture.


Or they can implement whatever works in their device to protect the keys.

The root CA is not a problem as it is offline except to make new 
intermediate CAs.  In fact for Singapore, I hope to have the root CA be 
a mSD card with Fedora26 for a Cubieboard2.  Pop the card in, and there 
is your root CA.  And a different mSD card for the signing CA!  I can do 
this all offline.  Just put the CSR on a USB drive and insert it in one 
of the Cubie's USB ports and sign away!


I just need to document this all.  That is all.  :)

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

[Sam Roberts]

Probably I misunderstand the context, since PKCS#8 can be used to
encrypt EC private key info, some more info at
https://tools.ietf.org/html/rfc5915. Which doesn't help the OP if the
openssl CLI doesn't support it.


On Mon, Aug 21, 2017 at 8:52 AM, Salz, Rich via openssl-users
 wrote:
> ➢ OK.  And why does DER not support encryption
>
> Because it is not defined.  If you want to encrypt keys, you need to use 
> PKCS12 which might be too much for your application.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

[Salz, Rich via openssl-users]

➢ OK.  And why does DER not support encryption

Because it is not defined.  If you want to encrypt keys, you need to use PKCS12 
which might be too much for your application.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

[Robert Moskowitz]

On 08/21/2017 11:43 AM, Salz, Rich via openssl-users wrote:

➢ But if I use format=der I do not get prompted for the password.

DER does not support encryption.  The bug is that the command does not tell you this.


OK.  And why does DER not support encryption?  Actually, I can see 
working around this.  The CA certs private keys can be in PEM and 
everything else in DER.  Provided I can get all the inform and outforms 
right.


But for now I will 'live' with unencrypted DER CA private keys.

Bob
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] problem with -aes256 and -outform der in cmmand

[Salz, Rich via openssl-users]

➢ But if I use format=der I do not get prompted for the password.
   
DER does not support encryption.  The bug is that the command does not tell you 
this.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] problem with -aes256 and -outform der in cmmand

[Robert Moskowitz]

If I use format=pem in the following:

openssl genpkey -outform $format -aes256 -algorithm ec -pkeyopt 
ec_paramgen_curve:prime256v1 \

-pkeyopt ec_param_enc:named_curve -out private/ca.key.$format

the private key is password protected.

But if I use format=der

I do not get prompted for the password.

The pem file is 379 bytes and the der is 121, but that is not a valid 
comparison as der is not encrypted...


Is this a bug?  Or a feature?

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Robert Moskowitz]

On 08/21/2017 10:03 AM, Salz, Rich wrote:

If the root is going to be trusted, make its serial number be one. ☺
Otherwise use eight bytes of random as the serial number, if you follow CABF 
guidelines.


Kind of where my thinking is going.  But once I make it '1', it might as 
well be 1 byte rand!  :)


Well 1 - 127 random...

But no need to make it 20 octets.  Just leave it at 8.  And yes, I can 
see some jump on the 'save' 7 bytes bandwagon.  Also why I have to work 
out BER to compare that sizing to DER.  Trying to do that today.


Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Salz, Rich via openssl-users]

If the root is going to be trusted, make its serial number be one. ☺
Otherwise use eight bytes of random as the serial number, if you follow CABF 
guidelines.
 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Robert Moskowitz]

On 08/21/2017 09:36 AM, Salz, Rich wrote:

➢ Thus how large does this random number have

It’s also to protect against predicting serial numbers and being able to 
leverage that.  It’s not just (nor really mainly) the MD5 digest attacks.  
According to CABForum, you need 8 octets.  No reason not to use more if you can.


Sure there is.  On constrained systems with constrained communication 
links.  Every byte counts.  My real thrust on this is for IoT.  To get 
IoT developers to build around certs and know their products work with 
them instead of, well we will get to it eventually.


When I work with 802.15.4 communications with a 128 byte MTU, there is 
considerable debate over every byte sent.  When you tell an IoT chip 
maker that they have to go from 32KB memory to 100MB, they walk out of 
the room.


Oh, I want DOTS and I2NSF developers to be working with certs from the 
get go, instead waiting for deployments and getting 'production' certs 
and THEN discovering what works and what does not.  But IoT is in many 
ways more of a challenge.


So yes, size matters.




➢ page was talking about in conjunction with the -CA option. With 'openssl
 ca' use of the serial file is mandatory according to the man page.
 There are no command line options for it.

Fixed in master and will be part of the next releases; the –rand_serial flag.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Salz, Rich via openssl-users]

➢ Thus how large does this random number have 

It’s also to protect against predicting serial numbers and being able to 
leverage that.  It’s not just (nor really mainly) the MD5 digest attacks.  
According to CABForum, you need 8 octets.  No reason not to use more if you can.


➢ page was talking about in conjunction with the -CA option. With 'openssl 
ca' use of the serial file is mandatory according to the man page.  
There are no command line options for it.

Fixed in master and will be part of the next releases; the –rand_serial flag.   
 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Robert Moskowitz]

On 08/21/2017 09:20 AM, Salz, Rich via openssl-users wrote:

 But in doing this, I can't figure out if there is a risk on serial
 number size for a root CA cert as there is for any other cert.

I don’t understand what attack you are concerned about, but the size of the 
serial number should not matter for *any* certificate.

This whole subject is tied into the substitution attack found with using 
an MD5 hash where you could change some things in the cert and still 
have a valid cert.  The solution, besides dropping MD5, was to include a 
crypto random number in the beginning of the cert, and the serial was 
chosen for this sacrifice.  Thus how large does this random number have 
to be to defend against this attack?  is 8 octets enough or is 20 needed?


This is to make another valid cert with a different keypair.  OK, I get 
this for a cert signed by an issuer.  But the root issuer?  I don't see 
the attack.  Thus no need to push the root cert's serial to 20 octets.


I know I am a little cavalier in describing the attack, but that was the 
basic point of why to move away from sequential serials to random and 
what size (though there are other things about CAs that can be 
discovered by analyzing the sequential serial numbers they used).


Meanwhile, I was wrong that -set_serial works with 'openssl ca'. The man 
page was talking about in conjunction with the -CA option. With 'openssl 
ca' use of the serial file is mandatory according to the man page.  
There are no command line options for it.


Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using set_serial to control serial number size directly

[Salz, Rich via openssl-users]

But in doing this, I can't figure out if there is a risk on serial 
number size for a root CA cert as there is for any other cert.

I don’t understand what attack you are concerned about, but the size of the 
serial number should not matter for *any* certificate.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Using set_serial to control serial number size directly

[Robert Moskowitz]

I have worked out that:

openssl req -config openssl-root.cnf -set_serial 0x$(openssl rand -hex 
19) -key private/ca.key.pem\

  -subj "$DN"\
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem



allows you to override the serial number select process and thus control 
what size serial number you use.


This also works for openssl ca for signing a csr, so you don't have to 
deal with the serial file.


You can further parameterize this with:

-set_serial 0x$(openssl rand -hex $sn)

when sn=some number 8 to 19.

But in doing this, I can't figure out if there is a risk on serial 
number size for a root CA cert as there is for any other cert.  The 
nature of the attack, just to me, does not seem to apply to a root CA 
cert.  So that a serial number size of 8 octets is just fine for the 
root cert.


Please correct me if I don't have the risk properly understood.

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Question about X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN for a cert chain including the root cert

[Bernhard Fröhlich]

Hi there,

I have a question about certificate chain checkin when the chain 
includes a root certificate.


The server I want to connect to with openssl s_client (Version 0.9.8zc) 
sends this certificate chain:


0 s:Server's cert
 i:Intermediate cert
1 s:Intermediate cert
 i:Root 1 cert
2 s:Root 1 cert
 i: Root 2 cert
3 s:Root 2 cert
 i:Root 2 cert

If my CA file includes the self signed Root 1 cert, but not the "Root 2 
cert" I get "Verify return code: 19 (self signed certificate in 
certificate chain)"

If I add the Root 2 cert to the CA file everything is fine.
If I try openssl verify on the Server's cert with a CA file including 
Intermediate cert and self-signed Root 1 cert, but not Root 2 cert, 
verify reports OK.


My view was that the Root 1 cert in the CA file should verify the chain. 
Obviously it does not, but why?
Are two certificates with the same subject but different issuer 
considered different? Or is this an issue with my ancient openssl version?


Kind regards
Ted

--
PGP Public Key Information
Key ID = 7AFB8D26
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users