Re: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.

[Erwann Abalea via openssl-users]

Assuming that all self-signed certificates are trusted (here, A and B),
then providing a CAfile with D+C+B+A to validate E, the different possible
paths are:
 - E <- D <- B: this path is valid
 - E <- D <- C <- A: this path is valid

In the validation algorithm described in RFC5280 and X.509, the
pathlenConstraints contained in the certificate of the Trust Anchor (here,
A or B) is not taken into account. Therefore, the only ones that matter are
the values set in C and D, and these values are coherent with both chains.


On Thu, Sep 15, 2022 at 7:34 PM Andrew Lynch via openssl-users <
openssl-users@openssl.org> wrote:

> Hi,
>
>
>
> I would like to have my understanding of the following issue confirmed:
>
>
>
> Given a two-level CA where the different generations of Root cross-sign
> each other, the verification of an end-entity certificate fails with
> OpenSSL 1.1.1 – “path length constraint exceeded”.  With OpenSSL 1.0.2 the
> same verify succeeds.
>
>
>
> All Root CA certificates have Basic Constraints CA:TRUE, pathlen:1.  The
> Sub CA certificate has pathlen:0.
>
>
>
> A) Issuer: CN=Root CA, serialNumber=1
>
>Subject: CN=Root CA, serialNumber=1
>
>
>
> B) Issuer: CN=Root CA, serialNumber=2
>
>Subject: CN=Root CA, serialNumber=2
>
>
>
> C) Issuer: CN=Root CA, serialNumber=1
>
>Subject: CN=Root CA, serialNumber=2
>
>
>
> D) Issuer: CN=Root CA, serialNumber=2
>
>Subject: CN=Sub CA, serialNumber=2
>
>
>
> E) Issuer: CN=Sub CA, serialNumber=2
>
>Subject: Some end entity
>
>
>
> With a CAfile containing D, C, B, A in that order the verify of E fails.
> If I remove the cross certificate C then the verify succeeds.
>
>
>
> I believe OpenSSL 1.1.1 is building a chain of depth 3 (D – C – A) and so
> pathlen:1 of A is violated.  Without the cross certificate the chain is
> only depth 2 (D – B).
>
>
>
> Is my understanding of the reason for this failure correct?
>
> Why is OpenSSL 1.0.2 verifying successfully?  Does it not check the path
> length constraint or is it actually picking the depth 2 chain instead of
> the depth 3?
>
>
>
> Regards,
>
> Andrew.
>
>
>


-- 
Cordialement,
Erwann Abalea.

Re: [EXTERNAL] Keytool issue with version 3.0.2.

[Erwann Abalea via openssl-users]

Bonjour,

OpenSSL 3 changed the default ciphers used to protect the private keys and
certificates when creating a PKCS#12, to use something less aging.

Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3 and see
if keytool can read it.


On Thu, May 19, 2022 at 11:53 AM Djordje Gavrilovic 
wrote:

> Hi guys,
> I have a following issue with migrating from version 1.1.1f to 3.0.2:
>
> I generate bmstore.pkcs12.pem file with the following commands:
>
> ```
>
> openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem -nodes
> -x509 -days 999 -out bmstore.x509.crt -subj
> "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS"
> openssl pkcs12 -export -in bmstore.x509.crt -inkey bmstore.pkcs8.pem
> -out bmstore.pkcs12.pem -passin pass:changeit -passout pass:changeit
> ```
>
> This file is genearted with different openssl versions differently. Both
> versions of the file are attached.
>
> Based on that file I generate:
>
> ```
> keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstoretype
> PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks
> -deststorepass changeit
> ```
>
> But keytool works only with the bmstore.pkcs12.pem generated with old
> version of openssl and creates bmstore.pkcs8.x509.jks
>
> The current version of openssl generates bmstore.pkcs12.pem in another
> format and keytool throws an exception:
>
> ```
> Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks...
> keytool error: java.io.IOException: keystore password was incorrect
>
> ```
>


-- 
Cordialement,
Erwann Abalea.

Re: [EXTERNAL] Using openssl-rsautl for verifying signatures.

[Erwann Abalea via openssl-users]

Bonjour,

The ASN.1 structure (it's a DigestInfo) is part of the PKCS#1 v1.5 padding
for signature operations.
PKCS#1v1.5 is rewritten in RFC2313.

Using the command line tool, you can reproduce this:

echo -n "Mary had a little lamb." > datatosign

either one of the following can be used to sign data:
  openssl dgst -sha1 -sign tests/keys/rsa_key1.key datatosign > signing
  openssl pkeyutl -inkey tests/keys/rsa_key1.key -in <(openssl dgst -sha1
-binary datatosign) -sign -pkeyopt digest:sha1 > signing

and you can display the signature either way (this will not "verify", it
will only perform the RSA verify operation with PKCS#1v1.5 padding, without
checking the validity or even if what has been signed is a DigestInfo
structure, and output the result of the RSA operation):
  openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -in signing
-asn1parse
  openssl pkeyutl -verifyrecover -inkey tests/keys/rsa_key1.pub -pubin
-in signing -asn1parse

or you can actually verify the thing without displaying the result of the
RSA verify crypto operation:
  openssl pkeyutl -verify -inkey tests/keys/rsa_key1.pub -pubin -in
<(openssl dgst -sha1 -binary datatosign) -sigfile signing -pkeyopt
digest:sha1
  openssl dgst -verify tests/keys/rsa_key1.pub -signature signing
-sha1 datatosign

On Wed, May 4, 2022 at 7:16 AM Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:

> Hi,
>
> I did the following in trying to build some validation steps to use
> against my own rewrite of the crypto functions in Asterisk (to use
> EVP-PKEY).
>
> % echo -n "Mary had a little lamb." | openssl sha1 -binary > digest
>
> % od -t x1 digest
> 000 4e 07 b8 c7 aa f2 a4 ed 4c e3 9e 76 f6 5d 2a 04
> 020 bd ef 57 00
> 024
>
> % openssl rsautl -sign -inkey tests/keys/rsa_key1.key -pkcs -in digest >
> signing
>
> % openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -pkcs -in
> signing > digest2
>
> % od -t x1 digest
> 000 4e 07 b8 c7 aa f2 a4 ed 4c e3 9e 76 f6 5d 2a 04
> 020 bd ef 57 00
> 024
>
> And all of that looks good.
>
> But when I take the result of calling:
>
> const char msg[] = "Mary had a little lamb.";
> unsigned msglen = sizeof(msg) - 1;
> char digest[20];
>
> /* Calculate digest of message */
> SHA1((unsigned char *)msg, msglen, digest);
>
> res = RSA_sign(NID_sha1, digest, sizeof(digest), dsig, ,
> key->rsa);
>
> And write that (dsig, siglen) to a file (signing2) and then try to verify
> that, I get very different results:
>
> openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -pkcs -in
> signing2  -asn1parse
> 0:d=0  hl=2 l=  33 cons: SEQUENCE
> 2:d=1  hl=2 l=   9 cons:  SEQUENCE
> 4:d=2  hl=2 l=   5 prim:   OBJECT:sha1
>11:d=2  hl=2 l=   0 prim:   NULL
>13:d=1  hl=2 l=  20 prim:  OCTET STRING
>    - 4e 07 b8 c7 aa f2 a4 ed-4c e3 9e 76 f6 5d 2a 04
>  N...L..v.]*.
>   0010 - bd ef 57 00   ..W.
>
> Why is RSA_sign() wrapping the signature in ASN.1?
>
> Or, put a different way, how do I reproduce what RSA_sign() is doing from
> the command line?
>
> Is there another command that does RSA signing besides rsautl?
>
> Thanks,
>
> -Philip
>
>
>

-- 
Cordialement,
Erwann Abalea.

Re: [EXTERNAL] Re: odd error for ECDSA key in REQ.

[Erwann Abalea via openssl-users]

The key itself is good. Its encoding in the CSR isn't.
Looks like the public key was X9.62 encoded in its uncompressed form (i.e. 
start with a 04 octet, and then the octets composing the x and y coordinates), 
and then wrapped into an ASN.1 OCTET STRING (i.e. use the 04 tag, plus a 0x41 
length, and the encoded public key), and finally the BIT STRING encapsulation.
The OCTET STRING is wrong here.

Cordialement,
Erwann Abalea

Le 08/08/2020 14:24, « openssl-users au nom de Dirk-Willem van Gulik » 
 a écrit :

The key is generated by a lovely HSM - which is by its nature a bit of a 
closed box. Whose vendor is very sure its software is right.

So this helps a lot - and helps confirm what we thought !

Thanks,

Dw

> On 8 Aug 2020, at 04:16, Frank Migge  wrote:
> 
> Hi Dirk-Willem,
> 
> Something is wrong with your EC key. The error mentions that it can't
> get the curve points from the key data. How did you generate the key?
> 
> If it helps, here is a working CSR example, using a prime256v1 key for
> comparison:
> 
> -BEGIN CERTIFICATE REQUEST-
> MIIBDjCBtAIBADArMQswCQYDVQQGEwJKUDEcMBoGA1UEAwwTdGVzdCBmb3IgcHJp
> bWUyNTZ2MTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOMQV0Vep+9Xnje6bKNy
> +8blwKEscr5LoUQCuwqaUT4HyPgXFE9E0r1PiWbC6bGkS26MuguOBp52X9H9z+NS
> zM6gJzAlBgkqhkiG9w0BCQ4xGDAWMBQGA1UdEQQNMAuCCWZtNGRkLmNvbTAKBggq
> hkjOPQQDAgNJADBGAiEA5uYlfkpRsJhBk+WwippCjupEpaCNaHwNyNqbj8qrR80C
> IQDCoJtaWhFGxbaAB2+o3gm87ZHJSDSjfrD2lEhlkbEXHQ==
> -END CERTIFICATE REQUEST-
> 
> 
> $ openssl req -inform PEM -noout -pubkey -in test.csr
> -BEGIN PUBLIC KEY-
> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4xBXRV6n71eeN7pso3L7xuXAoSxy
> vkuhRAK7CppRPgfI+BcUT0TSvU+JZsLpsaRLboy6C44GnnZf0f3P41LMzg==
> -END PUBLIC KEY-
> 
> 
> On Fri, 2020-08-07 at 19:07 +0200, Dirk-Willem van Gulik wrote:
>> Below CSR gives me an odd error with the standard openssl REQ
>> command:
>> 
>>  openssl req -inform DER -noout -pubkey
>> 
>>  Error getting public key
>> 
>>  140673482679616:error:10067066:elliptic curve
>> routines:ec_GFp_simple_oct2point:invalid
>> encoding:../crypto/ec/ecp_oct.c:312:
>>  140673482679616:error:10098010:elliptic curve
>> routines:o2i_ECPublicKey:EC lib:../crypto/ec/ec_asn1.c:1175:
>>  140673482679616:error:100D708E:elliptic curve
>> routines:eckey_pub_decode:decode error:../crypto/ec/ec_ameth.c:157:
>>  140673482679616:error:0B09407D:x509 certificate
>> routines:x509_pubkey_decode:public key decode
>> error:../crypto/x509/x_pubkey.c:125:
>> 
>> Even though the ASN1 of the public key looks correct to me:
>> 
>>SEQUENCE (2 elem)
>>  SEQUENCE (2 elem)
>>OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62
>> public key type)
>>OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62
>> named elliptic curve)
>>  BIT STRING (536 bit)
>> 01000101011110010011001110011100011010001010010110100
>> 0…
>>OCTET STRING (65 byte)
>> 0439339C68A5A333143592C0A36D053F31D3AF6ED18FB54F4747B9DFC6DB6ABC71556
>> 1…
>> 
>> What would be a good way to further debug this ?
>> 
>> With kind regards,
>> 
>> Dw
>> 
>> -BEGIN CERTIFICATE REQUEST-
>> MIIBPzCB5QIBADCBgDELMAkGA1UEAxMCQ04xCjAIBgNVBAUTATExCjAIBgNVBAYT
>> AUMxCjAIBgNVBAcTAUwxCjAIBgNVBAgTAVMxCjAIBgNVBAoTAU8xCzAJBgNVBAsT
>> Ak9VMQowCAYDVQQMEwFUMQowCAYDVQQNEwFEMRAwDgYJKoZIhvcNAQkBEwFFMFsw
>> EwYHKoZIzj0CAQYIKoZIzj0DAQcDRAAEQQQ5M5xopaMzFDWSwKNtBT8x069u0Y+1
>> T0dHud/G22q8cVVh8sVcpLUortLxxesEXCddpx/EeuxP+MN/RymHTMrjoAAwCgYI
>> KoZIzj0EAwIDSQAwRgIhAO+K+TFCdYxQg7aT+B3wIVa6CCYxM/mL4/WHSrwXujJy
>> AiEA7UsbQT/YRKaFDPn/U9jdrJaUmKsqKJvGwN7YVaMGdeo=
>> -END CERTIFICATE REQUEST-
> 
> 
> -- 
> Frank Migge
> http://fm4dd.com | pub...@frank4dd.com
> 

Re: [EXTERNAL] Re: Unusual certificates

[Erwann Abalea via openssl-users]

The second certificate seems garbaged at the 4th RDN of the issuerName.
The Base64 edition might have added or deleted some characters.

Cordialement,
Erwann Abalea

Le 25/06/2020 16:00, « openssl-users au nom de Angus Robertson - Magenta 
Systems Ltd »  
a écrit :

More information, the original certificates supplied by the end user
had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
email.  

If I try the asn1parse command on the wrapped certificates, they now
attempt to parse, the OK is fine, the bad one now gives an error
message from asn1parse:

Error in encoding
20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
long:crypto\asn1\asn1_lib.c:91:

and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
from PEM_read_bio_X509.  

The RFC says 'Parsers MAY handle other line sizes' but it would be good
if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
change my library code to check for line ending in the base64 to give
the user a polite message.  

Now the only problem is what is asn1 decoding unhappy with?

Angus

Re: client certs with no subjectName only SAN

[Erwann Abalea via openssl-users]

Bonjour,

Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, 
value=0xff). It may, as a side effect, enlarge the number of octets necessary 
to encode some structure size.

Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL 
keeps them by default).

If size is a hard constraint:
 - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 
octets). Depending on your use-case, you may need to tweak the EKU (or remove 
it completely).
 - SKI and AKI extensions may not be necessary
 - Key Usage may be marked as non critical (it's a SHOULD in PKIX)

A quick reading of RFC8002 tells me that you may need to include the 
IssuerAltName extension as well?

Cordialement,
Erwann Abalea

Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » 
 a écrit :

Viktor,


On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
>> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:
>>
>> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"
> This is wrong.  When the subject DN is empty, the subjectAltName should be
> marked as critical.  IIRC some Java implementations reject the certificate
> otherwise.

I have just created a client cert with empty subjectName and critical 
subjectAltName.  Interestingly, it is 4 bytes larger than the earlier 
non-critical SAN cert.  See below for the output of the cert.

>> I can believe that OpenSSL doesn't support empty subjectName's.  An 
empty one, with no relative disintuished name components, is not the same as 
not present.
> OpenSSL supports empty (empty RDN sequence) subject DNs.
> The "-subj /" option is one way to make that happen.
>
> Empty is of course different from "absent", which is not
> possible, since the subject DN is a required component of
> an X.509 certificate.

I now have it clear that Empty SN is NOT a cert with NO SN.  It is there 
with null content.

Thank you all.

$ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 c9:8f:b2:7b:e1:95:74:d0
 Signature Algorithm: ED25519
 Issuer: CN = 2001:24:28:14::/64
 Validity
 Not Before: Aug 16 14:54:58 2019 GMT
 Not After : Aug 25 14:54:58 2020 GMT
 Subject:
 Subject Public Key Info:
 Public Key Algorithm: ED25519
 ED25519 Public-Key:
 pub:
 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
 c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
 4c:a5
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Cert Type:
 SSL Client, S/MIME
 Netscape Comment:
 OpenSSL Generated Client Certificate
 X509v3 Subject Key Identifier:
8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
 X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

 X509v3 Key Usage: critical
 Digital Signature, Non Repudiation, Key Encipherment
 X509v3 Extended Key Usage:
 TLS Web Client Authentication, E-mail Protection
 X509v3 Subject Alternative Name: critical
 IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
 Signature Algorithm: ED25519
  01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
  4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
  dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
  ba:1a:b4:17:c0:bb:0f:da:be:02

Re: client certs with no subjectName only SAN

[Erwann Abalea via openssl-users]

Bonjour,

In the same paragraph, the sentence before the one you're quoting says "If the 
subject field contains an empty sequence, then the issuing CA MUST include a 
subjectAltName extension that is marked as critical."

It's not possible to have a missing subject name in a certificate, the field is 
not OPTIONAL.

Cordialement,
Erwann Abalea

Le 15/08/2019 22:13, « openssl-users au nom de Salz, Rich via openssl-users » 
 a écrit 
:

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"

I can believe that OpenSSL doesn't support empty subjectName's.  An empty 
one, with no relative disintuished name components, is not the same as not 
present.

Re: Why were edwards curves given distinct key types, aren't they EC keys?

[Erwann Abalea via openssl-users]

Maybe because EVP_PKEY_EC designates an ECDSA key, that an EdDSA key is not 
generated the same way (particularly the public part), and that the encodings 
are different?

Cordialement,
Erwann Abalea

Le 15/03/2019 19:20, « openssl-users au nom de Sam Roberts » 
 a écrit :

It seems like they are EC keys, with specific curve designs, and that
also have some algorithms designed specifically for them, like EdDSA
-- though it looks like that alg is being generalized to other curve
types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2).

What about them makes it necessary to make them distinct, both from
each other, and EVP_PKEY_EC?

Thanks,
Sam

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Erwann Abalea via openssl-users]

Bonjour,

Here, reject the certificate is the correct behaviour, IMO.

UTCTime/GeneralizedTime are defined in X.680.

UTCTime:
 - can have no timezone information, or have Z, of have a timezone offset (with 
hours and minutes)
 - can be precise up to the second, or be precise up to the minute
 - cannot have fractional seconds or minutes
 - cannot have second 60 (think of leap seconds) 
 - is not subject to ISO8601 rules

GeneralizedTime:
 - can have no timezone information, or have Z, of have a timezone offset 
(either hours, or hours and minutes)
 - can be precise up to the second with optional fractional seconds, or be 
precise up to the minute and have fractional minutes, or be precise up to the 
hour and have fractional hours (any number of decimal places)
 - shall follow ISO8601 rules (including leap seconds)
 - cannot support the "midnight at end of day" (24)


DER encoding (X.690) of these elements have of course stricter requirements:
 - the timezone shall be present and consist of Zulu time (Z), for UTC
 - the date/time shall be precise up to the second
 - if any fractional second is present, any trailing zero shall be omitted, and 
if there is no more decimal place, the trailing dot shall also be omitted

So in this case, the UTCTIME element containing "370308132808+" is not a 
valid DER encoding. That's not an RFC5280/X.509 difference.

There was a debate wether the tbsCertificate shall always be DER encoded or can 
be BER encoded and have the signature match the DER encoding, but it was closed 
from the ITU-T point of view in 1997 and first edition of X.509v3, by defining 
the SIGNED{} and SIGNATURE{} parameterized types and have additional text 
describing precisely the behaviour to adopt as a sender and receiver (first in 
clause 9, then moved to clause 6.1 in 2000, and clause 6.4 in 2012).
RFC5280 is far from being that clear.


OpenSSL added some checks on GeneralizedTime/UTCTime, by enforcing RFC5280 
rules. I haven't followed the source code to see if these checks also apply to 
data types other than RFC5280 certificates (RFC5652 CMS signingTime attribute, 
RFC3161 timestamps, RFC6960 OCSP responses, ...). I remember having debated 
regarding the support of leap seconds on GitHub, and it seems that second 60 is 
not supported at all (even if for a certified/qualiied timestamping service, 
that second can exist and is supposed to be produced).


Cordialement,
Erwann Abalea

Le 06/03/2019 16:38, « openssl-users au nom de Jakob Bohm via openssl-users » 
 a écrit 
:

On 06/03/2019 16:17, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf 
Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>>
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> as a follow-up:  Richard's analysis/suspicion was spot on.
>>> However, it was the *server* side certificate that was causing the
>>> error, and the server certificate does indeed contain a poorly
>>> formatted date:
>>>
>>> $ openssl asn1parse -in server.crt | grep UTC
>>>157:d=3  hl=2 l=  13 prim: UTCTIME   :091022132829Z
>>>172:d=3  hl=2 l=  17 prim: UTCTIME   :370308132808+
>> I'm glad I could help find the answer.
>>
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> Yup, 1.1+ is stricter regarding these things.
> I would have expected 1.0.2p and later to have rejected this as well, 
since the RFC 5280 restrictions on validity date attributes were included in 
that release. There was some discussion about it on the OpenSSL lists, with 
some people suggesting that a change to insist on the letter of the standard 
which broke compatibility with certificates generated by some other 
implementations was not a great idea. (I am sympathetic to this argument 
myself, and feel there should at least be an option to relax these 
restrictions.)
>
> See for example: 
https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>
> It's interesting to note that back in 2009 when GeneralizedTime support 
for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 
is only a profile of X.509, and X.509 itself allows timezone offsets and 
fracttional seconds, and so arguably OpenSSL ought to allow them too 
(presumably for use by non-TLS X.509 applications). (See e.g. 
http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
 Personally, I find that argument persuasive too, and think that it would be 
appropriate to have a mechanism to disable the 5280 checks.
>
> Maybe I'll put together a PR, though I don't know if it has much chance 
of being accepted.
>

RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.  So arguably,
it should 

Re: [openssl-users] RSA Public Key error

[Erwann Abalea via openssl-users]

Bonjour,

Without knowing what functions you’re calling when you try to encrypt data 
using the key Key3_wo16, I can only guess. And I’m guessing that you’re calling 
a function that expects to find a public key encoded in a SubjectPublicKeyInfo 
structure, and since this Key3_wo16 object is not such a structure, the 
function fails.

What you can do is :

  *   Take your public keys (for example Key2_w16)
  *   Check that the first 16 bytes are what you expect to have
  *   Pass the remainder of the file to the d2i_RSAPublicKey() function
  *   Use the resulting RSA public key the way you want

Cordialement,
Erwann Abalea


De : prithiraj das 
Date : lundi 17 décembre 2018 à 08:23
À : Erwann Abalea , "openssl-users@openssl.org" 

Objet : Re: [openssl-users] RSA Public Key error

Hi Erwann/All,

Thank you for your earlier response. I have done a couple of tests on the 
originally generated 2048-bit RSA public key (let's say Key1_org) and the key 
file containing 16 byte custom information after removing 24 bytes from the 
originally generated key file and prepending those 16 bytes (let's say 
Key2_w16). For my experiment(s), I also removed those 16 bytes from the key 
Key2_w16 (which contains custom information) and the rest of the bytes were 
written into a file. Lets name this keyfile Key3_wo16. I believe the presence 
of custom 16 byte information resulted in asn1parse encoding/decoding errors as 
mentioned in the previous mail..

So now, Key3_wo16  =  Key2_w16 - the first 16 bytes  =   Key1_org - the first 
24 bytes. And  I performed asn1parse on Key3_wo16. The output of asn1parse on 
this key is shown in the image file asn1parse of 24 byte removed.jpg which is 
attached in the mail. And I also performed 2 asn1parse strparse opertions on 
the originally generated public key Key1_org with strparse offsets 19 and 24. I 
have attached screenshots of the same with names asn1parse strparse 19.jpg and 
asn1parse strparse 24.jpg respectively. The outputs in all cases are the same. 
In the screenshots, the (removed/blurred) respective INTEGER values in all 
screenshots are the same.

What I want to know is why is OpenSSL throwing an error when try to encrypt 
data using the key Key3_wo16? The same command used for encryption works when 
the key Key1_org is used. I believe the INTEGER values contain the modulus and 
exponent information and so, I was expecting the encryption to be successful 
but OpenSSL fails to accept this key.

Can anyone please tell me what is going wrong here? Apart from the solution 
suggested by Erwann , can anyone please suggest an alternative solution as we 
need to work with the Key2_w16 ( the key containing the custom 16 byte 
information after removing the originally present first 24 bytes)? That is the 
only keyfile received by us.

Thanks and Regards,
Prithiraj

On Wed, 12 Dec 2018 at 12:32, Erwann Abalea via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Bonjour,

Assuming the first 24 bytes you’re talking about are the very beginning of the 
SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), 
that means you’ve replaced up to the first byte of the BITSTRING containing the 
public key (this byte indicates the number of unused bits) for a 2048bits RSA 
key with 16 custom bytes.
That’s perfectly normal for OpenSSL to refuse to load that beast, and for 
asn1parse to return errors (the first bytes do not represent a correct DER 
encoding of anything).
Think of it as « I took a Jpeg file, replaced some bytes at the beginning by my 
own, and now I can’t open the file again ». Those bytes are there for a reason.

A quick solution would be to *add* your 16 bytes before the public key, and 
remove them when passing the rest of the bytes to OpenSSL.

Cordialement,
Erwann Abalea


De : openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
au nom de prithiraj das 
mailto:prithiraj@gmail.com>>
Répondre à : "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" 
mailto:openssl-users@openssl.org>>
Date : mercredi 12 décembre 2018 à 08:08
À : "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" 
mailto:openssl-users@openssl.org>>
Objet : [openssl-users] RSA Public Key error

Hi,

I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere. That 
key has been obtained after removing the first 24 bytes from the originally 
generated RSA public key. Those 24 bytes are being replaced by some custom 16 
byte information which is being used as some sort of identifier in some future 
task and those 16 bytes are playing no role in encryption. OpenSSL fails to 
read this key. asn1parse shows some parsing error and most importantly RSA 
encryption in OpenSSL using this key fails. The untampered version of the RSA 
public key generated from the same source and containing the original 24 bytes 
at the beginning of the key is successfully read by OpenSSL and t

Re: [openssl-users] RSA Public Key error

[Erwann Abalea via openssl-users]

Bonjour,

Assuming the first 24 bytes you’re talking about are the very beginning of the 
SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), 
that means you’ve replaced up to the first byte of the BITSTRING containing the 
public key (this byte indicates the number of unused bits) for a 2048bits RSA 
key with 16 custom bytes.
That’s perfectly normal for OpenSSL to refuse to load that beast, and for 
asn1parse to return errors (the first bytes do not represent a correct DER 
encoding of anything).
Think of it as « I took a Jpeg file, replaced some bytes at the beginning by my 
own, and now I can’t open the file again ». Those bytes are there for a reason.

A quick solution would be to *add* your 16 bytes before the public key, and 
remove them when passing the rest of the bytes to OpenSSL.

Cordialement,
Erwann Abalea


De : openssl-users  au nom de prithiraj das 

Répondre à : "openssl-users@openssl.org" 
Date : mercredi 12 décembre 2018 à 08:08
À : "openssl-users@openssl.org" 
Objet : [openssl-users] RSA Public Key error

Hi,

I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere. That 
key has been obtained after removing the first 24 bytes from the originally 
generated RSA public key. Those 24 bytes are being replaced by some custom 16 
byte information which is being used as some sort of identifier in some future 
task and those 16 bytes are playing no role in encryption. OpenSSL fails to 
read this key. asn1parse shows some parsing error and most importantly RSA 
encryption in OpenSSL using this key fails. The untampered version of the RSA 
public key generated from the same source and containing the original 24 bytes 
at the beginning of the key is successfully read by OpenSSL and the RSA 
encryption using that key is also successful in OpenSSL. But our requirement is 
to use the first key containing the custom 16 byte information.

My understanding is that the first 24 bytes of RSA public key following PKCS 
standards doesn't contain the modulus and exponent details required for RSA 
encryption.  But OpenSSL seems to require these 24 bytes for encryption. Can 
someone please confirm what kind of information is present in the first 24 
bytes of RSA Public key and/or why does OpenSSL need it? If possible, please 
suggest a solution to work with that RSA public key containing custom 16 byte 
information at the beginning of the key.


Thanks and Regards,
Prithiraj
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Erwann Abalea via openssl-users]

Bonjour,

The prospective certification path excludes the Trust Anchor.
Therefore, the « max_path_length=0 » step is attained only when dealing with 
your EvilCA cert.

Cordialement,
Erwann Abalea

> Le 8 oct. 2018 à 14:47, Peter Magnusson  a 
> écrit :
> 
> That is not correct behaviour as far as I can understand.
> 
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
> 
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
> 
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
> 
>   The pathLenConstraint field is meaningful only if the cA boolean is
>   asserted and the key usage extension, if present, asserts the
>   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>   maximum number of non-self-issued intermediate certificates that may
>   follow this certificate in a valid certification path.  (Note: The
>   last certificate in the certification path is not an intermediate
>   certificate, and is not included in this limit.  Usually, the last
>   certificate is an end entity certificate, but it can be a CA
>   certificate.)  A pathLenConstraint of zero indicates that no non-
>   self-issued intermediate CA certificates may follow in a valid
>   certification path.  Where it appears, the pathLenConstraint field
>   MUST be greater than or equal to zero.  Where pathLenConstraint does
>   not appear, no limit is imposed.
> 
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
>> 
>> It was my interpretation that 0 pathlen on the root self signed meant 
>> infinite.
>> The pathlen only applies on the certs between root and the leaf (which 
>> obviously can be 0, and CA true or not, but bad form to say true I'd 
>> imagine.)
>> 
>> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
>>  wrote:
>>> 
>>> One more logic confusion in the OpenSSL Path Length Constraint check.
>>> Any Path Length Constraint set by Root (or any other Self-Issued
>>> Certificate) is ignored.
>>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>>> applied to the checker (i.e. the checker and the calculation logic
>>> have been mixed up).
>>> 
>>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>> 
>>> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>>>Certificate Sign, CRL Sign
>>>X509v3 Basic Constraints: critical
>>>CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>>>Certificate Sign, CRL Sign
>>>X509v3 Basic Constraints: critical
>>>CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>>>X509v3 extensions:
>>>X509v3 Basic Constraints: critical
>>>CA:FALSE
>>> 
>>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>X509v3 extensions:
>>>X509v3 Subject Key Identifier:
>>>49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> --
>>> --
>>>49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>>X509v3 Authority Key Identifier:
>>> 
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>>>X509v3 extensions:
>>>X509v3 Subject Key Identifier:
>>>B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>> --
>>> --
>>>B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>>X509v3 Authority Key Identifier:
>>> 
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>TLS Web Server Authentication
>>>X509v3 Subject Key Identifier:
>>>03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>> --
>>> --
>>>03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>>X509v3 Authority Key Identifier:

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Erwann Abalea via openssl-users]

> Le 13 sept. 2017 à 17:08, Michael Wojcik  a 
> écrit :
> 
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Michael Richardson
>> Sent: Wednesday, September 13, 2017 09:32
>> 
>> I suspect that the value: literal value 1231235959Z will simply come to
>> mean "the end of time", even after the year 10,000.  It has a well known
>> DER encoding, and one can memcmp() it.
> 
> Personally, I'm really hoping we're not still using ASN.1 in the year 1.

Why not? ;)

X.680 relies in ISO8601 for the date/time definitions. GeneralizedTime uses the 
Basic format from ISO8601 for the date (year on 4 digits, month on 2 starting 
with 01, day on 2 starting with 01), liberal time of day (minutes and/or 
seconds can be omitted, optional fraction of second/minute/hour depending on 
what is included), and a timezone from -15h to +15h with a one hour or one 
minute accuracy, or Z for UTC.

BER accepts pretty much everything from this definition, DER has a few 
restrictions:
 - in ISO8601, there are 2 different midnights (00:00:00 and 24:00:00), the DER 
encoding requires such date/time to be transformed into 00:00:00 the day after
 - DER only accepts the « Z » timezone and not the +/-HH(MM) variant
 - DER requires the minutes and seconds to be present in the time of day, and 
no fraction of a second

In theory, the very last date/time expressed in ASN.1 is 123124+1500, 
and it would be valid if expressed in BER. In DER, the very last date/time 
would have been 1231235960Z (in case a positive leap second gets inserted 
that day), but something else was preferred. It’s still possible that there’s a 
negative leap second happening at that exact day, removing second 59 completely.
Just think of this as a magical value.

Cordialement,
Erwann Abalea

-- 
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] More on cert serialnumbers

[Erwann Abalea via openssl-users]

> Le 18 août 2017 à 15:18, Mark H. Wood <mw...@iupui.edu> a écrit :
> 
> On Thu, Aug 17, 2017 at 03:29:56PM +, Erwann Abalea via openssl-users 
> wrote:
>> The BR are for public CAs, not private CAs; even if some of those 
>> requirements are considered « good practice » (the 64 bits out of a CSPRNG 
>> is such a req), they cannot be forced on private CAs.
>> And unless some or all of the browsers also apply these requirements to 
>> private CAs, you’re not forced to follow them all.
> 
> How does one mechanically distinguish public vs. private CAs?

OS/Browser-granted or user-granted. Each browser does it differently.

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

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Erwann Abalea via openssl-users]

> Le 17 août 2017 à 17:36, Jeffrey Walton  a écrit :
> 
> On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
>  wrote:
>> 
>>> Le 17 août 2017 à 17:26, Jeffrey Walton  a écrit :
>>> 
> When you see a name like "example.com" in the CN, its usually a CA
> including a domain name and not a hostname.
 
 That's nonsense.
>>> 
>>> If a certificate is issued under CA/B policies, and CN=example.com but
>>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>>> not be matched.
>> 
>> Such a certificate would be mis-issued and be revoked immediately. CN MUST 
>> be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the 
>> value in CN MUST be present in the SAN extension.
> 
> Oh, you would have some fun watching how various user agents handle
> that scenario. For your first stop, check out how OpenSSL handles it.

I’m sure some user agents can have strange behaviors on such certificates. My 
remark took into consideration the CA/B policies. If such a certificate falls 
down under the CA/B policies (issued by a public CA, and a TLS server 
certificate), then it’s invalid.
Some browsers (maybe all?) ignore the CN if the SAN extension is present, even 
for private CAs.

Cordialement,
Erwann Abalea

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

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Erwann Abalea via openssl-users]

> Le 17 août 2017 à 17:26, Jeffrey Walton  a écrit :
> 
>>> When you see a name like "example.com" in the CN, its usually a CA
>>> including a domain name and not a hostname.
>> 
>> That's nonsense.
> 
> If a certificate is issued under CA/B policies, and CN=example.com but
> it _lacks_ SAN=example.com, then its a not a hostname and it should
> not be matched.

Such a certificate would be mis-issued and be revoked immediately. CN MUST be 
an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in 
CN MUST be present in the SAN extension.

Cordialement,
Erwann Abalea

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

Re: [openssl-users] More on cert serialnumbers

[Erwann Abalea via openssl-users]

Bonjour,

> Le 17 août 2017 à 17:10, Robert Moskowitz  a écrit :
> 
> 
> 
> On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:
>> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes. 
>>  Which means, you want to make sure the high bit is off, else the DER 
>> encoding will make it 21 bytes.
>> 
>> So the new –rand_serial flag I am adding to the CA command will make call 
>> RAND_bytes to get 18 bytes.
>> 
>> 
>> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" 
>>  wrote:
>> 
>> https://cabforum.org/2016/07/08/ballot-164/
> 
> “Effective September 30, 2016, CAs SHALL generate Certificate serial numbers 
> greater than zero (0) containing at least 64 bits of output from a CSPRNG.”
> 
> What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial 
> number is OK?  Or 2^64 bit serial number represented in HEX (how long is 
> that?)

That means that the serial number SHALL be at least 64 bits (8 octets) long, 
and at least 64 of the bits of the serial number come from a cryptographically 
strong pseudo random number generator.

The BR are for public CAs, not private CAs; even if some of those requirements 
are considered « good practice » (the 64 bits out of a CSPRNG is such a req), 
they cannot be forced on private CAs.
And unless some or all of the browsers also apply these requirements to private 
CAs, you’re not forced to follow them all.

The 20 octets max comes from RFC5280, keep it.
MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant 
anymore).
The 64 bits from a CSPRNG is a tradeoff allowing the use of a 
non-collision-resistant hash function for slightly longer for transition 
periods, it’s nice if you can easily follow it, but browsers probably won’t 
enforce it.
The 2048bits minimum RSA key is really a good practice and shouldn’t be left 
over. Switch to ECDSA if your target permits it.
The CN deprecation and use of SAN:dNSName instead is a target of some browsers 
for private CAs; it may require more work for you, but there’s a benefit. CN 
has been populated with too much garbage (FQDN, domain, service name, IP 
address, person name, …), the SAN extension has nice baskets to put your eggs 
in (dNSName and iPAddress), and it works beautifully with NameConstraints.

Cordialement,
Erwann Abalea

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

Re: [openssl-users] keyusage digitalSignature in CA certs

[Erwann Abalea via openssl-users]

Bonjour,

> Le 17 août 2017 à 15:20, Robert Moskowitz  a écrit :
> 
> Should digitalSignature be included in keyusage in CA certs?

It depends on what you plan to do with the corresponding private key.
If you want this private key to sign messages other than certificates and CRLs 
(such as OCSP responses), then yes.

> 
> https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
> 
> Includes it.
> 
> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
> 
> Does not include it.
> 
> It seems to make a root or intermediate CA be able to have more purposes than 
> it should?  e.g.
> 
> SSL client : Yes
> SSL server : Yes
> S/MIME signing : Yes

This is the result of an analysis of the keyUsage *and* the extendedKeyUsage 
extensions (and maybe obsolete Netscape proprietary ones).

> So which is the right for a CA's key usage?

That really depends on what you want it to be valid for.

keyUsage=keyCertSign is fine for certificate signing
keyUsage=cRLSign is fine for CRL signing
keyUsage=digitalSignature is fine for OCSP signing

The other bits are not that common for a CA.

You can achieve the capabilities with different certificates.

For example, a keyCertSign-only CA cert can self-issue a cRLSign certificate in 
order to produce CRLs and a digitalSignature certificate to sign OCSP 
responses, or an issuing CA can issue different certificates for the same CA 
(they all have the same Subject, which is different from the issuing’s Subject) 
but for different purposes (and thus different keyUsage bits).

Cordialement,
Erwann Abalea

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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Erwann Abalea via openssl-users]

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 
>> > 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 is ever going
>>to see your certs, then who cares what’s in them?
>> 
>> 
>> Well, I do like to abide by specs, and they will be used in various 
>> browsers, so I think I will continue the unique serial numbering.
>> 
>> Thanks, Rich.
> 
> Modern browsers increasingly presume that such private CAs behave exactly
> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
> the per-browser root CA inclusion programs (the administrative processes
> that determine which CAs are listed in browsers by default).
> 
> Among the relevant requirements now needed:
> 
> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
> numbers and as DER-encoded numbers.  Note that this is not the default in
> the openssl ca program.

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 the openssl ca program.

It can be easily done by an external script. Generate a secret key for your CA 
for a 128bits block cipher, keep the monotonic counter, but instead of putting 
the value of the counter in the serial number, encrypt the counter with the 
key+cipher, and use the resulting cipher text as the serial number. Of course, 
increment the counter.

> - Certificates are valid for at most 2 years (actually 825 days).
> 
> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
> is already disappearing from Browser code.
> 
> - RSA shorter than 2048 bits (and other weak settings such as equally short
> DSA keys) are no longer permitted and is already disappearing from Browser
> code.
> 
> - If the certificate is issued to an e-mail address, that e-mail address must
> also be listed as an rfc822Name in a "Subject Alternative Name" certificate
> extension.
> 
> - End user certificates must be issued from an Intermediary CA whose
> certificate is is in turn issued from a longer term root CA.

I doubt browsers impose this on purely private CAs.

> - If revocation is implemented (it should be, just in case someone gets their
> computer or other key storage hacked/stolen), it needs to support OCSP, but
> should ideally do so without having the actual CA keys online (standard trick:
> Issue 3-month non-revocable OCSP-signing certificates and provide the
> corresponding private key to the server running the OCSP responder program).
>  I would recommend to also implement traditional CRLs, since for smaller CAs
> it is a better solution for browsers and servers that support it.

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.

Cordialement,
Erwann Abalea

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