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 requ

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
>>> --
>>> --

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 <michael.woj...@microfocus.com> 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 <r...@htt-consult.com> 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 <noloa...@gmail.com> a écrit :
> 
> On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
> <erwann.aba...@docusign.com> wrote:
>> 
>>> Le 17 août 2017 à 17:26, Jeffrey Walton <noloa...@gmail.com> 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 <noloa...@gmail.com> 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 <r...@htt-consult.com> 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" 
>> <openssl-users@openssl.org> 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 <r...@htt-consult.com> 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 <jb-open...@wisemo.com> a écrit :
> 
> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users 
>> <openssl-users@openssl.org <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
>>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

Re: [openssl-users] Understanding RSA_sign and type argument

[Erwann Abalea]

Bonjour,

Add « -sigalgs SHA256+RSA » to one of your command lines.

Cordialement,
Erwann Abalea

Le 9 juin 2017 à 09:45, Ignacio Alamo Corsino 
<nacao2...@hotmail.com<mailto:nacao2...@hotmail.com>> a écrit :

Hello everyone,

i am having some issues understanding the RSA_sign function:

RSA_sign(int type, const unsigned char *m, unsigned int m_len, unsigned char 
*sigret, unsigned int *siglen, RSA *rsa);

As far as I know, the signing is a four step process:
- Calculate hash with digest algorithm  (given as argument to this 
function -> m)
- Encapsulate hash in a DigestInfo structure (X509_SIG)
- Structure padding (in RSA_private_encrypt)
- Private key operation on this padded structure (in RSA_private_encrypt)

Is that correct?

So, during the TLS handshake, the RSA_sign function is called in the 
CertificateVerify step.
For my tests, everytime this function is called, the hashing type is SHA512 
even though I specify to use a SHA256 hash.

These are the commands that I use to test TLS:

#openssl s_server -accept 443 -cert cert.pem -key key.pem  -Verify 1 -msg 
-debug -cipher eNULL:aRSA:!SHA512:SHA256 -serverpref
#openssl s_client -connect localhost:443 -cert client_cert.pem   -key 
client.key -state -cipher eNULL:aRSA:!SHA512:SHA256

How can I force TLS to use a SHA256 digest for DH?
--
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] Leading Zeros in ASN1_INTEGER?

[Erwann Abalea]

Why not?

This serial number could also be displayed as 3203232750, or 000BEED73EE, or 
03203232750.

Cordialement,
Erwann Abalea

Le 30 janv. 2017 à 11:03, Matthias Ballreich 
<matthias.ballre...@outlook.de<mailto:matthias.ballre...@outlook.de>> a écrit :

thanks for explanation.

But why did Windows Cert Manager and Firefox Cert Manager show 00BEED73EE as 
serial number instead of BEED73EE (which openssl shows)?


Von: openssl-users 
<openssl-users-boun...@openssl.org<mailto:openssl-users-boun...@openssl.org>> 
im Auftrag von Viktor Dukhovni 
<openssl-us...@dukhovni.org<mailto:openssl-us...@dukhovni.org>>
Gesendet: Samstag, 28. Januar 2017 17:00:53
An: openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Betreff: Re: [openssl-users] Leading Zeros in ASN1_INTEGER?


> On Jan 28, 2017, at 10:01 AM, Matthias Ballreich 
> <matthias.ballre...@outlook.de<mailto:matthias.ballre...@outlook.de>> wrote:
>
> is it normal that OpenSSL removes the leading Zeros in an ASN1_INTEGER?
> I tried to read the Certificate Serial and the Certificate Serial in the
> AuthorityKeyID-Extension with C++, which works very well, but i noticed
> that OpenSSL removes the leading Zeros on it.
>
> The real ASN1-Value is: 00BEED73EE for example, but i got only BEED73EE.
> If i view the Certificate inside Microsoft Cert Tool (Certmgr.exe) the
> leading Zeros are listed there. Same on Firefox, if i Import and view
> the Certificate there. So is this the correct way of handling inside
> OpenSSL or is it a bug or?

Integers don't have leading zeros.  Octet strings representing integers
(in non-DER form) might have leading zeros, but you should not confuse
the data type with its representation.  OpenSSL outputs the correct DER
form of the serial *number* in certificates.

Leading zeros are needed in the DER representation of positive integers
whose most significant nibble is in the range from 8 to F.  Otherwise
the leading bit would cause the integer to be interpreted as negative.

--
Viktor.

--
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

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

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

[Erwann Abalea]

ISO/C 2011, clause 6.3.2.3:

An integer constant expression with the value 0, or such an expression cast to 
type void *, is called a null pointer constant. If a null pointer constant is 
converted to a pointer type, the resulting pointer, called a null pointer, is 
guaranteed to compare unequal to any object or function.

Conversion of a null pointer to another pointer type yields a null pointer of 
that type. Any two null pointers shall compare equal.


int *var1 = 0;
int *var2 = (void*)0;

result in var1 and var2 to both be null pointers (the null pointer constant 
being « 0 » or « (void*)0 »).

This doesn’t matter if your specific machine encodes null pointers as 
‘0x'.

On your specific machine, however:

int *var1;
int *var2 = 0;
memset(var1, 0, sizeof(var1));

won’t make var1 be a null pointer, but var2 will internally contain this 
0x, and will be a null pointer.


Cordialement,
Erwann Abalea

> Le 11 janv. 2017 à 17:18, Jeffrey Walton <noloa...@gmail.com> a écrit :
> 
>> Could someone from the OpenSSL team please explain the rationale for this
>> decision? What is the problem with using assignments with 0 or NULL to
>> initialize pointers?
> 
> I'm not from the team, so take it for what its worth...
> 
> On some systems, NULL is _not_ 0. NULL can be anywhere in memory the
> architecture wants it to be. It can be in a high page in memory, too.
> One of my instructors in college was telling me about a system he
> worked on where NULL was an address in the last page in memory, so it
> took a value like `0x`.
> 
> Jeff
> -- 
> 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] (SPAM) Retrieving Root CA certificate using "openssl s_client -showcerts" command

[Erwann Abalea]

Bonjour,

The root certificate is not expected to be sent by the server, as it already 
needs to be known and trusted by the client.
However, you’re free to configure your server to send it, for debugging or 
informational purposes.

Cordialement,
Erwann Abalea

Le 8 nov. 2016 à 03:36, Mofassir Ul Haque 
<mofassir_ha...@yahoo.com<mailto:mofassir_ha...@yahoo.com>> a écrit :

Hi All,

The output of "openssl s_client -showcerts -connect ..." command dose not 
include Root certificate (which is expected behaviour). However, is it possible 
to configure Server to return Root CA certificate also ?

Thanks,

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

Re: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0

[Erwann Abalea]

Bonjour,

Something like this?

/*

MyChoice ::= CHOICE {
  anInteger INTEGER,
  anOctetString OCTET STRING
  anASCIIString IA5STRING
}

MyStruct ::= SEQUENCE {
  item1 MyChoice
}

*/

__ File mytypes.h __

#include 

#define ASN1_OBJECT_dup(x) 
ASN1_dup_of(ASN1_OBJECT,i2d_ASN1_OBJECT,d2i_ASN1_OBJECT,x)
#define DECLARE_ASN1_DUP_FUNCTION(stname) stname * stname##_dup(stname *x);

typedef struct {
  int type;
  union {
ASN1_INTEGER *anInteger;
ASN1_OCTET_STRING *anOctetString;
ASN1_IA5STRING *anASCIIString;
  } value;
} MYCHOICE;

DECLARE_ASN1_FUNCTIONS(MYCHOICE)
DECLARE_ASN1_DUP_FUNCTION(MYCHOICE)
DECLARE_ASN1_PRINT_FUNCTION(MYCHOICE)
#define d2i_MYCHOICE_bio(bp,p) ASN1_d2i_bio_of(MYCHOICE, MYCHOICE_new,d2i_ 
MYCHOICE,bp,p)
#define i2d_MYCHOICE_bio(bp,o) ASN1_i2d_bio_of(MYCHOICE,i2d_ MYCHOICE,bp,o)
#define d2i_MYCHOICE_fp(fp,p) ASN1_d2i_fp_of(MYCHOICE, MYCHOICE_new,d2i_ 
MYCHOICE,fp,p)
#define i2d_MYCHOICE_fp(fp,p) ASN1_i2d_fp_of(MYCHOICE,i2d_ MYCHOICE,fp,p)


typedef struct {
  MYCHOICE *item1;
} MYSTRUCT;

DECLARE_ASN1_FUNCTIONS(MYSTRUCT)
DECLARE_ASN1_DUP_FUNCTION(MYSTRUCT)
DECLARE_ASN1_PRINT_FUNCTION(MYSTRUCT)
#define d2i_MYSTRUCT_bio(bp,p) ASN1_d2i_bio_of(MYSTRUCT, MYSTRUCT_new,d2i_ 
MYSTRUCT,bp,p)
#define i2d_MYSTRUCT_bio(bp,o) ASN1_i2d_bio_of(MYSTRUCT,i2d_ MYSTRUCT,bp,o)
#define d2i_MYSTRUCT_fp(fp,p) ASN1_d2i_fp_of(MYSTRUCT, MYSTRUCT_new,d2i_ 
MYSTRUCT,fp,p)
#define i2d_MYSTRUCT_fp(fp,p) ASN1_i2d_fp_of(MYSTRUCT,i2d_ MYSTRUCT,fp,p)


__ File mytypes.c __
#include 
#include "mytypes.h"

ASN1_CHOICE(MYCHOICE) = {
  ASN1_SIMPLE(MYCHOICE, value.anInteger, ASN1_INTEGER),
  ASN1_SIMPLE(MYCHOICE, value.anOctetString, ASN1_OCTET_STRING),
  ASN1_SIMPLE(MYCHOICE, value.anASCIIString, ASN1_IA5STRING)
} ASN1_CHOICE_END(MYCHOICE)

IMPLEMENT_ASN1_FUNCTIONS(MYCHOICE)
IMPLEMENT_ASN1_DUP_FUNCTION(MYCHOICE)
IMPLEMENT_ASN1_PRINT_FUNCTION(MYCHOICE)


ASN1_SEQUENCE(MYSTRUCT) = {
  ASN1_SIMPLE(MYSTRUCT, item1, MYCHOICE)
} ASN1_SEQUENCE_END(MYSTRUCT)

IMPLEMENT_ASN1_FUNCTIONS(MYSTRUCT)
IMPLEMENT_ASN1_DUP_FUNCTION(MYSTRUCT)
IMPLEMENT_ASN1_PRINT_FUNCTION(MYSTRUCT)


Now you can call i2d_MYSTRUCT()/d2i_MYSTRUCT() to encode/decode such a data 
type, and similar _bio, _fp, _dup functions as well.

Cordialement,
Erwann Abalea

Le 20 sept. 2016 à 11:45, Aleksandr Konstantinov 
<aleksandr.v.konstanti...@gmail.com<mailto:aleksandr.v.konstanti...@gmail.com>> 
a écrit :

Hello,

Thanks a lot. One more question if possible. Is there any way to express single 
element of the ASN1 sequence which can be any of ASN1_OCTET_STRING or 
ASN1_UTF8STRING and potentially other types?
Or maybe there is some tutorial for new interface similar to something like 
http://www.umich.edu/~x509/ssleay/asn1-macros.html for old one?

Best regards,


A.K.



On Mon, Sep 19, 2016 at 3:05 PM, Dr. Stephen Henson 
<st...@openssl.org<mailto:st...@openssl.org>> wrote:
On Mon, Sep 19, 2016, Aleksandr Konstantinov wrote:

>
> Thanks. Your answer helped a lot and I'm progressing now. Could You please
> also give me a hint what M_ASN1_BIT_STRING_dup/ASN1_BIT_STRING_dup could be
> replaced with?
>

ASN1_STRING_dup should work fine: ASN1_BIT_STRING is actually typedefed to
ASN1_STRING.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: 
http://www.openssl.org<http://www.openssl.org/>
--
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

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

Re: [openssl-users] openssl crl fails to parse a CRL file, which seems correct

[Erwann Abalea]

That’s a bug in the Issuer name length check.
Use the 1.1.0 version.

Cordialement,
Erwann Abalea

> Le 14 sept. 2016 à 14:31, Wouter Verhelst <wouter.verhe...@fedict.be> a écrit 
> :
> 
> Hi,
> 
> (this is a resend because my MUA crashed while I tried to send this mail 
> earlier. If you get it twice, my apologies)
> 
> When I try to parse some of the CRLs at <http://crl.eid.belgium.be/>, I 
> sometimes get this error:
> 
> wouter@gangtai:~$ openssl version
> OpenSSL 1.0.2h  3 May 2016
> wouter@gangtai:~$ openssl crl -in eidc201203.crl -inform der -noout -text
> unable to load CRL
> 140694432685592:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too 
> long:x_name.c:203:
> 140694432685592:error:0D08303A:asn1 encoding 
> routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
> error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO
> 140694432685592:error:0D08303A:asn1 encoding 
> routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=crl, 
> Type=X509_CRL
> 
> This isn't the case for all of the CRLs, just for some of them; e.g., 
> everything works fine for eidc201503.crl
> 
> However, if I try the same on another machine nearby, which has a much older 
> version of OpenSSL, then things seem to work fine:
> 
> eidmac:~ buildslave$ openssl version
> OpenSSL 0.9.8zh 14 Jan 2016
> eidmac:~ buildslave$ openssl crl -in eidc201203.crl -inform der -noout -text 
> | head
> Certificate Revocation List (CRL):
> Version 2 (0x1)
> Signature Algorithm: sha1WithRSAEncryption
> Issuer: /C=BE/CN=Citizen CA/serialNumber=201203
> Last Update: Sep 14 10:22:50 2016 GMT
> Next Update: Sep 21 10:22:50 2016 GMT
> CRL extensions:
> X509v3 Authority Key Identifier:
> keyid:7A:5F:3A:FF:2D:46:91:90:53:3F:BB:91:2D:29:82:ED:BB:78:6A:E0
> 
> This machine is a mac running OSX 10.11, the OpenSSL is the default as 
> shipped with that OS; the other is my personal laptop, which runs Debian 
> unstable (and the openssl is again the default). I've reproduced the same 
> issue on Debian stable, haven't tried much else yet.
> 
> I've been trying to figure out why my OpenSSL fails to parse the CRL, whereas 
> others do not,. Any hints would be greatly appreciated.
> 
> Thanks,
> 
> -- 
> Wouter Verhelst
> -- 
> 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] Openssl software failure for RSA 16K modulus

[Erwann Abalea]

Bonjour,

Le 22 juil. 2016 à 08:44, Gupta, Saurabh 
> a écrit :


1: I didn't get it, Why this behaviour is not coming for other ciphers while 
doing the server/client handshake?

It should fail for other ciphers also.


Ciphers:  working

DHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
.. etc

Because the key exchange is performed using DHE or ECDHE here, and parameters 
are much smaller than your server authentication key.
If you configure a 16k DH group and choose to use DHE as the key exchange 
algorithm, you’ll surely fall under the same error.

Ciphers: Not working
AES128-SHA
AES256-SHA
.. etc

RSA key exchange.

2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue 
so that it won't harm to other application or create any new attack?

3: ECC cipher is not my main concerned.

You should be concerned about the security provided by your choices, and not 
pure raw numbers.


4: I didn't face any issue like memory utilisation or CPU utilisation is more 
if I'm running more than one client in the case of 16k modulus.

Your measuring tools are bad, change them ;)
Signing with a 16k RSA key is way slower than with a 2048bits key, and again 
way slower than using ECC.

According to NIST, equivalent « security levels »:
RSA15360, DH15360, ECC512 (or 521)
RSA7680, DH7680, ECC384
RSA3072, DH3072, ECC256

Measurements done on my machine:
Signing with ECDSA over the P521 curve is 600x faster than signing with a 
15kRSA key.
Performing a key exchange with ECDH over the P521 curve is about 180x faster 
than decrypting with a 15k RSA key.

Using the P384 curve and a 7kRSA key, the numbers are 180x faster and 50x 
faster.
Using the P256 curve and a 4kRSA key, numbers are about 90x faster for both 
operations.

I don’t have any measurements for DH key exchange, but it should cost twice 
more than doing a private RSA operation, and also impacts the client, and when 
used within TLS it comes in addition to an RSA signing operation.

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

Re: [openssl-users] Openssl software failure for RSA 16K modulus

[Erwann Abalea]

> Le 21 juil. 2016 à 15:08, Salz, Rich  a écrit :
> 
>> By raising the limit, you don’t suddenly put every application at risk of a 
>> DoS,
>> because these applications won’t suddenly use a 16k RSA key.
> 
> Yes we do, because the other side could send a key, not local config.

Server A code is modified to accept client key exchange messages up to 4kB.
Server A is configured with a 2048bits RSA key.

Client A connects to Server A, initiates the TLS handshake, receives the 
certificate, properly generates a 2048bits client key exchange message (using 
RSA key exchange), sends the message (about 260 octets); Server A accepts it 
and will do the job.

Client B connects to Server A, initiates the TLS handshake, receives the 
certificate, but for whatever reason decides to send a client key exchange 
message composed of what could be a 16kb RSA block (about 2056 bytes); Server A 
will accept the message, but will refuse to perform the RSA decryption (because 
it’s larger than the modulus length).

I don’t see where the harm can hide. There’s no more CPU eaten, network 
transfer has already happened at this moment, memory is already allocated.

Again, I’m not saying using a 16kRSA key is a good idea. It’s not a good idea, 
one should really consider ECC instead (both for performance and network 
reasons). But keeping this 2048 bytes limit is not a security decision. It’s 
the result of a trade-off choice, right. And that doesn't make it a bad 
decision either.

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

Re: [openssl-users] Openssl software failure for RSA 16K modulus

[Erwann Abalea]

> Le 21 juil. 2016 à 14:17, Salz, Rich  a écrit :
> 
>> We have to make trade-offs.  Who uses a 16K RSA key?
> 
> Let me add some  clarification.  Is it worth putting every application that 
> uses OpenSSL at risk for a DoS attack with a 16K RSA key?

By raising the limit, you don’t suddenly put every application at risk of a 
DoS, because these applications won’t suddenly use a 16k RSA key.
Anyway, OpenSSL 1.0.2+ now sets some limits on message sizes (defensive), some 
tradeoffs have to be done on those limits. According to some sources (NIST and 
ECRYPT II), 16k RSA provides an equivalent security level of a 512bits ECC key.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl software failure for RSA 16K modulus

[Erwann Abalea]

Largest accepted client key exchange message length seems to be set to 2048 
bytes.
Key exchange for an RSA16k is slightly larger than that (exactly 2048 bytes of 
pure crypto payload, plus a few bytes of overhead).

OpenSSL is too conservative here.

Cordialement,
Erwann Abalea

Le 21 juil. 2016 à 10:32, Gupta, Saurabh 
<saurabh.gu...@cavium.com<mailto:saurabh.gu...@cavium.com>> a écrit :

This issue, I'm facing for openssl-1.0.2e/g/h version.

Run openssl server: Used 16K Certificate and Key
./openssl s_server -cert sercert16384.pem -key server16384

Run openssl client:
./openssl s_client -connect :port_number -cipher AES128-SHA -tls1

ERROR

139812135450280:error:1408E098:SSL routines:ssl3_get_message:excessive message 
size:s3_both.c:417:


This error is coming while using AES128-SHA as a cipher and tls1/1_1/1_2 
protocols. It's working fine with ssl3 protocol.

Note:
1. This issue, I didn't face for the openssl-1.0.1p/e version.

Can you please confirm. is this known issue?
if it is the known issue. Can you please share that fix?

Regards,
Saurabh
--
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] Creating an X25519-based Certificate

[Erwann Abalea]

Maybe we just didn’t. At least not with the command line tools.
The CHANGES file lists a merge between « dh », « gendh », and « dhparam » in 
2000, but no evolution since then.
The oldest version I could find is 0.9.6, and there’s no command-line DH key 
generation.

Cordialement,
Erwann Abalea

Le 30 juin 2016 à 16:58, Jakob Bohm 
<jb-open...@wisemo.com<mailto:jb-open...@wisemo.com>> a écrit :

Which brings back my generalized question from yesterday:

Since X25519 is not the first "encrypt-only" algorithm in the
OpenSSL universe, how was requesting certificates handled for
such algorithms in the past?

For example how would one request a DH certificate?

Whatever was defined back then might be trivially extended
to also handle X25519.


On 30/06/2016 10:37, Erwann Abalea wrote:
Ok, you’re talking about OpenSSL command line tool only, I missed that part.

The solution should then be to modify apps/ca.c:certify() function to add an 
arg, and avoid the call to X509_REQ_verify when desired.

Le 29 juin 2016 à 19:17, Michael Scott 
<<mailto:mike.sc...@miracl.com>mike.sc...@miracl.com<mailto:mike.sc...@miracl.com>>
 a écrit :

Thanks Erwann, but that's not an answer to my question.

To get the CA to sign (using RSA or anything) a certificate that contains an 
X25519 public key, that certificate must first submit to the CA something 
called a "Certificate request". This takes the form of the supplicant 
certificate, which is self-signed. However you cannot self-sign with an X25519 
key (using the openssl command line tool), as it objects that X25519 does not 
support signature.

So the issue arises around the "certificate request" process. There is I agree 
no problem in creating the certificate itself.

On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea 
<erwann.aba...@docusign.com<mailto:erwann.aba...@docusign.com>> wrote:
Bonjour,

You may have a classic certificate containing your {X,Ed}{25519,448,whatever} 
public key once:

  *   an OID is allocated to identify this type of public key (it will go into 
tbs.subjectPublicKeyInfo.algorithm.algorithm)
  *   a set of associated optional parameters are defined for this OID (to go 
into tbs.subjectPublicKeyInfo.algorithm.parameters)
  *   a canonical encoding for this type of public key is defined, so the key 
material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey

This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in 
fact).

For a CA to be able to Ed{25519,448,whatever}-sign something, the previous 
steps must have been done, plus:

  *   an OID is allocated to identify the signature algorithm to apply (it will 
not be ECDSA) -> cert.signatureAlgorithm.algorithm
  *   a set of associated optional parameters are defined for this OID -> 
cert.signatureAlgorithm.parameters
  *   a canonical encoding for the signature value is defined, so it can be 
enclosed into cert.signatureValue

All this is being discussed at CFRG.

Le 29 juin 2016 à 16:46, Michael Scott 
<<mailto:mike.sc...@miracl.com>mike.sc...@miracl.com<mailto:mike.sc...@miracl.com>>
 a écrit :

How do I do this? Using the OpenSSL command line tool, a certificate request 
must be self-signed, but the X25519 elliptic curve (newly supported in version 
1.1.0), doesn't do signature, it can only be used for key exchange.

(Of course the X25519 Montgomery curve is birationally equivalent to an Edwards 
curve which can do signature. And indeed it is our intention to use the Edwards 
curve. But first I need a CA-signed X25519 cert. But because of the above 
catch-22 problem, I cannot create one.)


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  
https://www.wisemo.com<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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Creating an X25519-based Certificate

[Erwann Abalea]

Ok, you’re talking about OpenSSL command line tool only, I missed that part.

The solution should then be to modify apps/ca.c:certify() function to add an 
arg, and avoid the call to X509_REQ_verify when desired.

Cordialement,
Erwann Abalea

Le 29 juin 2016 à 19:17, Michael Scott 
<mike.sc...@miracl.com<mailto:mike.sc...@miracl.com>> a écrit :

Thanks Erwann, but that's not an answer to my question.

To get the CA to sign (using RSA or anything) a certificate that contains an 
X25519 public key, that certificate must first submit to the CA something 
called a "Certificate request". This takes the form of the supplicant 
certificate, which is self-signed. However you cannot self-sign with an X25519 
key (using the openssl command line tool), as it objects that X25519 does not 
support signature.

So the issue arises around the "certificate request" process. There is I agree 
no problem in creating the certificate itself.


Mike



On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea 
<erwann.aba...@docusign.com<mailto:erwann.aba...@docusign.com>> wrote:
Bonjour,

You may have a classic certificate containing your {X,Ed}{25519,448,whatever} 
public key once:

  *   an OID is allocated to identify this type of public key (it will go into 
tbs.subjectPublicKeyInfo.algorithm.algorithm)
  *   a set of associated optional parameters are defined for this OID (to go 
into tbs.subjectPublicKeyInfo.algorithm.parameters)
  *   a canonical encoding for this type of public key is defined, so the key 
material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey

This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in 
fact).

For a CA to be able to Ed{25519,448,whatever}-sign something, the previous 
steps must have been done, plus:

  *   an OID is allocated to identify the signature algorithm to apply (it will 
not be ECDSA) -> cert.signatureAlgorithm.algorithm
  *   a set of associated optional parameters are defined for this OID -> 
cert.signatureAlgorithm.parameters
  *   a canonical encoding for the signature value is defined, so it can be 
enclosed into cert.signatureValue

All this is being discussed at CFRG.

Cordialement,
Erwann Abalea

Le 29 juin 2016 à 16:46, Michael Scott 
<mike.sc...@miracl.com<mailto:mike.sc...@miracl.com>> a écrit :

Hello,


How do I do this? Using the OpenSSL command line tool, a certificate request 
must be self-signed, but the X25519 elliptic curve (newly supported in version 
1.1.0), doesn't do signature, it can only be used for key exchange.

(Of course the X25519 Montgomery curve is birationally equivalent to an Edwards 
curve which can do signature. And indeed it is our intention to use the Edwards 
curve. But first I need a CA-signed X25519 cert. But because of the above 
catch-22 problem, I cannot create one.)


Mike


--
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


--
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] Creating an X25519-based Certificate

[Erwann Abalea]

Bonjour,

You may have a classic certificate containing your {X,Ed}{25519,448,whatever} 
public key once:

  *   an OID is allocated to identify this type of public key (it will go into 
tbs.subjectPublicKeyInfo.algorithm.algorithm)
  *   a set of associated optional parameters are defined for this OID (to go 
into tbs.subjectPublicKeyInfo.algorithm.parameters)
  *   a canonical encoding for this type of public key is defined, so the key 
material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey

This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in 
fact).

For a CA to be able to Ed{25519,448,whatever}-sign something, the previous 
steps must have been done, plus:

  *   an OID is allocated to identify the signature algorithm to apply (it will 
not be ECDSA) -> cert.signatureAlgorithm.algorithm
  *   a set of associated optional parameters are defined for this OID -> 
cert.signatureAlgorithm.parameters
  *   a canonical encoding for the signature value is defined, so it can be 
enclosed into cert.signatureValue

All this is being discussed at CFRG.

Cordialement,
Erwann Abalea

Le 29 juin 2016 à 16:46, Michael Scott 
<mike.sc...@miracl.com<mailto:mike.sc...@miracl.com>> a écrit :

Hello,


How do I do this? Using the OpenSSL command line tool, a certificate request 
must be self-signed, but the X25519 elliptic curve (newly supported in version 
1.1.0), doesn't do signature, it can only be used for key exchange.

(Of course the X25519 Montgomery curve is birationally equivalent to an Edwards 
curve which can do signature. And indeed it is our intention to use the Edwards 
curve. But first I need a CA-signed X25519 cert. But because of the above 
catch-22 problem, I cannot create one.)


Mike


--
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] (SPAM) I: Question on ccm mode in openssl

[Erwann Abalea]

Bonjour,

CCM mode is already implemented in OpenSSL.

Cordialement,
Erwann Abalea

Le 24 mai 2016 à 17:43, Christian Adja 
<christian_a...@yahoo.it<mailto:christian_a...@yahoo.it>> a écrit :



Il Martedì 24 Maggio 2016 17:21, Christian Adja 
<christian_a...@yahoo.it<mailto:christian_a...@yahoo.it>> ha scritto:


Good morning, i'm a master student at telecom paristech, i France, i'm working 
on openssl to add ieee and etsi certs for client. I saw that the ccm mode is 
not implemented in current openssl 1.0.2g version. So i would know if there a 
way to add the ccm mode? Thanks.

Best regards


--
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] Is the structure of this CMS object correct?

[Erwann Abalea]

Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser 
> a écrit :

Hi,

I'm trying to decrypt a DER-encoded CMS object (created by Adobe Acrobat) with 
OpenSSL 1.0.2d:

$ openssl cms -decrypt -in recipient.bin  -inform DER -inkey atssecp521r1.key 
-recip atssecp521r1.pem
Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding 
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested 
asn1 error:tasn_dec.c:336:Field=d.kari, Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding 
routines:ASN1_TEMPLATE_EX_D2I:nested asn1 
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

The full dumpasn1 output of the file "recipient.bin" is below at the end of the 
message. Is this a correct CMS object?

If I compare this to the structure of a CMS object that was generated by 
OpenSSL itself, there's a difference in the structure of the RecipientInfos 
object. If I understand it correctly, this is the start of the RecipientInfos 
object (starting at line 6 of the dumpasn1 output):

  SET {
[1] {
  SEQUENCE {
INTEGER 3
…

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
   ktri KeyTransRecipientInfo,
   kari [1] KeyAgreeRecipientInfo,
   kekri [2] KEKRecipientInfo,
   pwri [3] PasswordRecipientinfo,
   ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
   version CMSVersion,  -- always set to 3
   originator [0] EXPLICIT OriginatorIdentifierOrKey,
   ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
   keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
   recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was changed 
between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori elements are 
associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
 issuerAndSerialNumber IssuerAndSerialNumber,
 subjectKeyIdentifier [0] SubjectKeyIdentifier,
 originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
 algorithm AlgorithmIdentifier,
 publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with the same 
certificate as the problematic one, the structure of the RecipientInfos object 
looks like this:

  SET {
[1] {
  INTEGER 3
  …

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.

This is the correct behavior of an IMPLICIT tag.

Another issue in the Acrobat-generated CMS object is the top-level CMSVersion 
in the EnvelopedData object being 0. I believe this is wrong and should be 2, 
but apparently OpenSSL doesn't care.

Full output of dumpasn1 for "recipient.bin" file:

SEQUENCE {
  OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
  [0] {
SEQUENCE {
  INTEGER 0
  SET {
[1] {
  SEQUENCE {

This is wrong, the SEQUENCE is to be hidden by the [1] tag.

INTEGER 3
[0] {

The [0] introduces the originator element, of type OriginatorIdentifierOrKey, 
it’s EXPLICIT.

  [1] {
SEQUENCE {

Also wrong, the [1] here should be IMPLICIT and hide the SEQUENCE tag of the 
OriginatorPublicKey structure.

  SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
}
  BIT STRING
  04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
  5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
  1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
  55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
  9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
  3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
  B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
  93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
  [ Another 

Re: [openssl-users] Is the structure of this CMS object correct?

[Erwann Abalea]

Bonjour Stephan,


Le 9 févr. 2016 à 12:29, Stephan Mühlstrasser 
<s...@pdflib.com<mailto:s...@pdflib.com>> a écrit :

Am 09.02.16 um 11:53 schrieb Erwann Abalea:
Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser 
<s...@pdflib.com<mailto:s...@pdflib.com>
<mailto:s...@pdflib.com>> a écrit :
...

 SET {
   [1] {
 SEQUENCE {
   INTEGER 3
   …

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  kekri [2] KEKRecipientInfo,
  pwri [3] PasswordRecipientinfo,
  ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 3
  originator [0] EXPLICIT OriginatorIdentifierOrKey,
  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was
changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori
elements are associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
 issuerAndSerialNumber IssuerAndSerialNumber,
 subjectKeyIdentifier [0] SubjectKeyIdentifier,
 originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
 algorithm AlgorithmIdentifier,
 publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with
the same certificate as the problematic one, the structure of the
RecipientInfos object looks like this:

 SET {
   [1] {
 INTEGER 3
 …

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present
here.

This is the correct behavior of an IMPLICIT tag.

many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime" command. 
Do I understand it correctly then that the input file is neither a correct 
PKCS#7 file nor a correct CMS file?

PKCS#7 and CMS are pretty much interchangeable.
Here, your file is strictly not a PKCS#7v1.5, because in this version, 
RecipientInfo wasn’t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).

How did you generate this structure? Adobe Acrobat?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP service dependant on time valid CRLs

[Erwann Abalea]

Bonjour,

The problem with signing with a default certificate is that the response 
certainly won’t be accepted by the client (see RFC6960 section 4.2.2.2, this 
responder certificate doesn’t follow criteria 1 and 2, and certainly not 
criteria 3), so you’re performing a signature knowing it will be rejected by a 
compliant client. It is also unwise from your side, because anybody can send a 
request for free, and as a result you’ll perform a signature: non negligible 
CPU cost and the response is larger than the request. An unsigned error message 
may be better.

« Unknown » is *a* correct answer in that specific case, not the only correct 
one. « tryLater » and « internalError » are equivalently correct answers. « 
Good », « malformedRequest », and « sigRequired » are NOT correct answers. « 
unauthorized » may also be considered a correct answer, but others may 
disagree. « Revoked » may seem a correct answer also, but not quite (see below).
The meaning of those different results is explained in RFC6960 and RFC5019.
Of course, if you’re using CRLs as an authoritative source of certificate 
status, RFC5280 is to be read also.

Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL 
validation, you’ll see that:
- at step (a)(1)(ii), you don’t get a newer CRL, so you can’t continue the 
algorithm
- after the algorithm, reasons_masks is still the empty set, and cert_status 
still has the value UNREVOKED, so the revocation status has NOT been determined
- last paragraph of 6.3.3 tells you that in the end, if the revocation status 
has not been determined, return a cert_status UNDETERMINED.

An OCSP service based on a CRL, given an expired CRL, running this normative 
algorithm, will get a cert_status « UNDETERMINED », and not a value stating 
that it’s revoked. Such an OCSP service, responding « Revoked », wouldn’t be 
strictly compliant.

Erwann Abalea
erwann.aba...@docusign.com<mailto:erwann.aba...@docusign.com>

Le 10 déc. 2015 à 20:07, socket 
<danbrya...@gmail.com<mailto:danbrya...@gmail.com>> a écrit :

Thanks for chiming in Erwann.  This OCSP service is CRL based. The software I 
am using has a "default signing certificate". I also have #X CA specific 
signing certificates for each CA in our lab PKI. It chooses to use the default 
signing certificate for all unknown issuers (like if someone explicitly queries 
the service for a microsoft timestamp certificate).

I appreciate your definitive response regarding  that the correct answer in 
this situation is to return unknown. I recognize your name as an authority in 
pkix, but is this documented anywhere? I would like to be able to justify to my 
customer that this is indeed the correct response.

Also, it seems weird to me that validating this certificate against the expired 
CRL returns a status of revoked, but when validating this same certificate 
against the OCSP service it says unknown. I guess i just have to get over that 
they are different and that a certificate can have a different status depending 
on who you ask.

Looking forward to any follow on thoughts...

--Dan

On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden 
email]> wrote:
Bonsoir,

The OCSP responder can respond « unknown » if it doesn’t know the status of the 
requested certificate. « Unknown » can generally not be used when the issuer is 
not known, because such a response is signed, and if the responder doesn’t know 
about the issuer, it can’t choose its own certificate to use to sign the 
response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, 
wrong signature, incomplete in scope, expired, whatever…), « unknown » is a 
correct answer. « revoked » is also a correct answer if an expired CRL is found 
declaring the requested certificate as revoked. « tryLater » is also a correct 
answer, even « internalError » if we consider the CRL as part of the internal 
state of the responder.

Erwann Abalea
[hidden email]<http://user/SendEmail.jtp?type=node=61627=0>

Le 10 déc. 2015 à 18:29, socket <[hidden 
email]<http://user/SendEmail.jtp?type=node=61627=1>> a écrit :

Hi Walter,

I agree with your addition regarding the fact that it is not saying the cert is 
good, it's saying unknown. However, my understanding of the RFC is that unknown 
should be returned when the OCSP service does not know about the certificate 
issuer. I'm not sure that's the case.

Regarding the response verification, we are used the CA Designated Responder 
(Authorized Responder). meaning that the issuer of serial 0x500c8bd was the 
same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing 
shows that this only affects the "response verification (OK/FAILED)" not the 
certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden email]> wrote:
Hi Dan,

On 10.12.2015 16:27, daniel bryan wrote:
TEST 

Re: [openssl-users] OCSP service dependant on time valid CRLs

[Erwann Abalea]

Bonsoir,

The OCSP responder can respond « unknown » if it doesn’t know the status of the 
requested certificate. « Unknown » can generally not be used when the issuer is 
not known, because such a response is signed, and if the responder doesn’t know 
about the issuer, it can’t choose its own certificate to use to sign the 
response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, 
wrong signature, incomplete in scope, expired, whatever…), « unknown » is a 
correct answer. « revoked » is also a correct answer if an expired CRL is found 
declaring the requested certificate as revoked. « tryLater » is also a correct 
answer, even « internalError » if we consider the CRL as part of the internal 
state of the responder.

Erwann Abalea
erwann.aba...@docusign.com<mailto:erwann.aba...@docusign.com>

Le 10 déc. 2015 à 18:29, socket 
<danbrya...@gmail.com<mailto:danbrya...@gmail.com>> a écrit :

Hi Walter,

I agree with your addition regarding the fact that it is not saying the cert is 
good, it's saying unknown. However, my understanding of the RFC is that unknown 
should be returned when the OCSP service does not know about the certificate 
issuer. I'm not sure that's the case.

Regarding the response verification, we are used the CA Designated Responder 
(Authorized Responder). meaning that the issuer of serial 0x500c8bd was the 
same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing 
shows that this only affects the "response verification (OK/FAILED)" not the 
certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden 
email]> wrote:
Hi Dan,

On 10.12.2015 16:27, daniel bryan wrote:
TEST #2: Next test was using OCSP:

[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile 
VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert 
CERTS/0x500c8bd-revoked.pem -url 
http://ocspresponder:8080<http://ocspresponder:8080/>

Response verify OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT

as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an 
OCSP service should provide a revoked response regardless of the time validity 
of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the 
same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both 
CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter

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

Re: [openssl-users] using openssl to validate an external AES program

[Erwann Abalea]

Bonjour,

> Le 9 oct. 2015 à 12:20, karel-de-ma...@wanadoo.fr a écrit :
> 
[…]
> Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
> Key : 0x06a9214036b8a15b512e03d534120006
> IV : 0x3dafba429d9eb430b422da802c9fac41
> Plaintext : "Single block msg"
> Ciphertext: 0xe353779c1079aeb82708942dbe77181a
> 
> the command line i launch is the following
> 
> :~/git/aes/openssl$ od -c clear3.txt
> 000 S i n g l e b l o c k m s g
> 020
> openssl enc -nosalt -aes-128-cbc -in clear3.txt -e -out test.enc -K 
> 06a9214036b8a15b512e03d534120006 -iv 3dafba429d9eb430b422da802c9fac41
> 
> :~/git/aes/openssl$ od -x test.enc
> 000 53e3 9c77 7910 b8ae 0827 2d94 77be 1a18
> 020 7cb9 5e82 781c 4651 2d54 6939 bc41 5de5
> 040
> 
> The first 16 bit are the answer given but what are the 16 following one ?

Padding, so the decryption process knows how many useful octets were encrypted. 
In your case, since the block is full, padding adds another block.

> 
> bellow that, my own program is AES-128 , not aes-128-cbc but for a msg of 16 
> bit only and a nul iv there should be no difference for what i understand.
> 
> but when i use the following number found here :
> 
> http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
> 
> PLAINTEXT: 00112233445566778899aabbccddeeff
> KEY:
> 000102030405060708090a0b0c0d0e0f
> 
> round[10].output 69c4e0d86a7b0430d8cdb78070b4c55a
> 
> i get the following
> 
> :~/git/aes/openssl$ od -x clear2.txt
> 000 1100 3322 5544 7766 9988 bbaa ddcc ffee
> 020
> :~/git/aes/openssl$ openssl enc -nosalt -in clear2.txt -out encrypted.dat -e 
> -aes-128-cbc -k 000102030405060708090a0b0c0d0e0f -iv 
> 

-k is not the same as -K.


Cordialement,
Erwann Abalea

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

[Erwann Abalea]

Bonjour,

> Le 9 sept. 2015 à 14:17, Georgi Guninski  a écrit :
> 
> On Wed, Sep 09, 2015 at 12:07:43PM +, Viktor Dukhovni wrote:
>>> 
>>> Are you saying I can't sign the cert with another cert
>>> (the pubkey is easy to extract from the cert) with openssl?
>> 
>> If you control a trusted root CA, or an intermediate CA issued
>> (possibly indirectly) by a trusted root CA, you can sign anything
>> you want and it will be trusted.  The fact that malfeasant CAs can
>> compromise security is not new.
>> 
>> If you don't control a trusted CA, what significance would such a
>> signature carry?  Yes, most certificates (sometimes constrained by
>> KeyUsage) can be used for signing, but unless "CA=true", they can't
>> be used to sign other certificates that will be trusted by peers.
>> 
> 
> I am gonna leave this list very soon.
> 
> Feel free to CC me with answer:
> 
> If I am CA and sign cert requests with vanilla openssl,
> will I sign a composite $q$?

If you’re a CA and sign cert requests, you’re responsible to check the public 
key you’re signing.
You could also sign an RSA key with e=1 or a dumb modulus, and it’s not a 
backdoor in RSA or OpenSSL.


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

Re: [openssl-users] Converting Bin format to X509 format

[Erwann Abalea]

Bonjour,

An X.509 certificate is:

Certificate  ::=  SEQUENCE  {
tbsCertificate   TBSCertificate,
signatureAlgorithm   AlgorithmIdentifier,
signatureValue   BIT STRING  }

What you produced with « openssl rsautl -sign » is the content of the « 
signatureValue » element (not its BIT STRING structure, only the inner content).
What is missing is all the rest, and it can’t be produced by the sole « openssl 
x509 … » command.

Please refine your question.

Cordialement,
Erwann Abalea



 Le 22 juil. 2015 à 11:17, Anirudh Raghunath anirudhraghun...@rocketmail.com 
 a écrit :
 
 Hello,
 
 I have used rsault -sign option to sign a text file which gives me a binary 
 file. I would like to convert this to X509 so that I can use it in a ssl 
 handshake. I understand the command:
 
 openssl x509 -inform format -in certfile -out cert.pem 
 
 is used. I want to know what the parameters would be for a binary input file.
 
 Thanks in advance. 
 ___
 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] Converting Bin format to X509 format

[Erwann Abalea]

Long response short, yes, you can.
Prepare and fill in your X509 object, perform the signature with your EVP_PKEY 
private key, format the resulting signature into a BIT STRING, place this BIT 
STRING into your previous X509 object, complete it with the AlgorithmIdentifier 
you choose when signing (it should already have been set in the TBSCertificate 
structure, just copy it from there).
The resulting X.509 certificate can be used for anything and is not limited for 
a SSL client verification usage.

In the previous paragraph, I assume your smart card contains the CA private 
key, and you want to sign certificates (either subCA or subscriber, it doesn’t 
matter). That’s how I understood your question.

If you want to do all this using only openssl CLI, that’s doable with a 
specially crafted config file declaring your engine and its parameters.

Cordialement,
Erwann Abalea



 Le 22 juil. 2015 à 11:57, Anirudh Raghunath anirudhraghun...@rocketmail.com 
 a écrit :
 
 Thanks for the quick response. I am currently working with smart cards and am 
 using the engine provided by openSC to access the private key in the smart 
 card. Long story short I have the EVP_PKEY object with me. Can I use this to 
 sign a certificate or some file which can be used for SSL client 
 verification. 
 
 Merci
 
 
 
 On Wednesday, 22 July 2015 11:52 AM, Erwann Abalea 
 erwann.aba...@opentrust.com wrote:
 
 
 Bonjour,
 
 An X.509 certificate is:
 
 Certificate  ::=  SEQUENCE  {
 tbsCertificate   TBSCertificate,
 signatureAlgorithm   AlgorithmIdentifier,
 signatureValue   BIT STRING  }
 
 What you produced with « openssl rsautl -sign » is the content of the « 
 signatureValue » element (not its BIT STRING structure, only the inner 
 content).
 What is missing is all the rest, and it can’t be produced by the sole « 
 openssl x509 … » command.
 
 Please refine your question.
 
 Cordialement,
 Erwann Abalea
 
 
 
 Le 22 juil. 2015 à 11:17, Anirudh Raghunath anirudhraghun...@rocketmail.com 
 mailto:anirudhraghun...@rocketmail.com a écrit :
 
 Hello,
 
 I have used rsault -sign option to sign a text file which gives me a binary 
 file. I would like to convert this to X509 so that I can use it in a ssl 
 handshake. I understand the command:
 
 openssl x509 -inform format -in certfile -out cert.pem 
 
 is used. I want to know what the parameters would be for a binary input file.
 
 Thanks in advance. 
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users 
 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] OCSP: ocsp.omniroot.com/baltimore/... - what is it exactly?

[Erwann Abalea]

Bonjour,

Le 30/04/2015 19:44, Tomasz Chmielewski a écrit :
This might not be very relevant to OpenSSL, but I'm not sure if there 
is any better list for this question...


My webserver is getting flooded with queries like:

ocsp.omniroot.com 124.205.254.7 - - [30/Apr/2015:19:24:30 +0200] GET 
/baltimoreroot/MEowSKADAgEAMEEwPzA9MAkGBSsOAwIaBQAEFMEvRXbtFVnssF26ib%2BdgHjlI9QTBBTlnVkwgkdYzKz6CFQ2hns6tQRN8AIEByekag%3D%3D 
HTTP/1.1 301 184 - ocspd/1.0.3


ocsp.omniroot.com 222.161.249.75 - - [30/Apr/2015:19:24:33 +0200] GET 
/baltimoreroot/MEUwQzBBMD8wPTAJBgUrDgMCGgUABBTBL0V27RVZ7LBduom%2FnYB45SPUEwQU5Z1ZMIJHWMys%2BghUNoZ7OrUETfACBAcnqkc%3D 
HTTP/1.1 301 184 - Microsoft-CryptoAPI/6.1



If I understand it right, because the query was sent to my server 
(China's Great Firewall DNS poisoning at works), and not to original 
ocsp.omniroot.com, somebody's browser or device was not able to verify 
if the certificate is still valid or not - am I correct here?


I don't remember the exact behaviour of the first client (I guess it's 
an Apple machine) on receiving this answer. For the Microsoft one, the 
client will try to get the CRL, and should also try a POST request to 
the OCSP responder, but I don't remember which one is tried first.


Is it possible to say what Common name / fqdn / certificate is 
queried in such requests?


Not directly.

The first request asks for the status of certificate whose serial number 
is 0x0727A46A, the second for the certificate with serial number 
0x0727AA47, both certificates are issued under the same CA, this CA is 
the root C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root.
If you can crawl a certificates database (there are several out there), 
you can probably find the exact requested certificate (it should be a 
CA, too).


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

Re: [openssl-users] NID_Name equivalent in a certificate

[Erwann Abalea]

Bonjour,

NID_name correspond to the OID id-at-name. There's no equivalent field 
in a certificate that maps to an OID.
The OID id-at-name designs the attribute supertype name, which 
shouldn't be present in a certificate, but can nevertheless be present. 
Anywhere.


--
Erwann ABALEA

Le 29/04/2015 07:19, Mailer Mailer a écrit :

Hi,

Can some one let me know what is the equivalent field in a certifcate 
that maps to NID_Name?


Thank you,
Tom


___
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] Delete a post to openssl-user mailing list

[Erwann Abalea]

Bonjour,

The password pwd1234 is obviously a test one, as is the file path 
c:/work/mypemfile.pem.

Knowing that you're using OpenSSL 1.0.2a shouldn't be a problem either.

What is the security risk?

--
Erwann ABALEA

Le 22/04/2015 15:55, Vollaro, John a écrit :

Can a message be removed by the system administrator of the openssl-user email 
forum?

My original post about  NULL EVP_PKEY was flag by my company as a security 
risk.
The data in the post was fake. I have been directed to remove the post if 
possible.

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Viktor Dukhovni
Sent: Tuesday, April 21, 2015 8:13 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Delete a post to openssl-user mailing list

On Tue, Apr 21, 2015 at 09:21:47PM +, Vollaro, John wrote:


Is it possible to remove a message I posted to the openssl-user email forum?

No.



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

Re: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?

[Erwann Abalea]

Le 04/04/2015 05:31, Jakob Bohm a écrit :

(top posting like the rest of the thread)


(I don't like it either, but that's what Thunderbird proposes by default).


What makes you think it is incorrect to check the Key
Identifier (where present) before checking a signature
against a key?


Because the presented file4.pem is a valid issuer certificate for the 
one found in file3.pem?
RFC5280 section 6.1 gives the validation algorithm, and the Key 
Identifier isn't mentioned.
6.1.3(a) checks for signature, validity, revocation status, and names 
(i.e. that issuercert.subjectName = cert.issuerName).


You're not supposed to follow exactly the same algorithm (or the one 
described in X.509), but whatever you choose, the result MUST be equivalent.



What other reasonable purpose could the Key Identifier
fields serve?


A helper to build a certificate chain to be passed to the validation 
algorithm.



On 03/04/2015 10:56, Erwann Abalea wrote:
 (Forwarded to openssl-users)

 The subjectName of file4.pem matches the issuerName of
 file3.pem, the signature block in file3.pem, when verified
 with the public key of file4.pem, gives a correct signature
 for the tbsCertificate of file3.pem. But Openssl also
 (incorrectly, IMO) checks that file4.pem.SKI matches
 file3.pem.AKI, and refuses to go further (here, AKI doesn't
 match SKI).

 Le 03/04/2015 03:10, Yuting Chen a écrit :
  I used OpenSSL to verify a certificate file (file3.pem)
  against another certificate file (file4.pem). OpenSSL
  reports that it cannot find the issuer of the cert in
  file3.pem; while when I displays file3.pem and file4.pem,
  it appears that the issuer of the cert in file3.pem is the
  same as the subject of the cert in file4.pem. Did I miss
  anything?

P.S.

Don't put your e-mail sig in the middle of the mail, it causes
standards-compliant mail programs to cut off everything below
it when replying (because everyting below the --space marker
is, by definition, just the e-mail sig).


I know, I often forget to manually switch between corporate and hard 
core modes. And Thunderbird doesn't help.


--
Erwann ABALEA

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

[openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?

[Erwann Abalea]

(Forwarded to openssl-users)

The subjectName of file4.pem matches the issuerName of file3.pem, the 
signature block in file3.pem, when verified with the public key of 
file4.pem, gives a correct signature for the tbsCertificate of file3.pem.
But Openssl also (incorrectly, IMO) checks that file4.pem.SKI matches 
file3.pem.AKI, and refuses to go further (here, AKI doesn't match SKI).


--
Erwann ABALEA

Le 03/04/2015 03:10, Yuting Chen a écrit :
I used OpenSSL to verify a certificate file (file3.pem) against 
another certificate file (file4.pem). OpenSSL reports that it cannot 
find the issuer of the cert in file3.pem; while when I displays 
file3.pem and file4.pem, it appears that the issuer of the cert in 
file3.pem is the same as the subject of the cert in file4.pem. Did I 
miss anything?




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

[openssl-users] Fwd to openssl-users, Re: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken

[Erwann Abalea]

The private key is a random integer in [1, p-1], not in [2^(log2(p)-1), 
(2^log2(p))-1].
In DER, an INTEGER is always expressed using the smallest possible 
number of octets. 001a is an integer equal to 001a, but it 
will be represented as 1a.


--
Erwann ABALEA

Le 24/03/2015 12:10, Annie Yousar a écrit :

Dear all,
this should not have happened:

$ for i in  `seq 1 1000` ; do if [ x`openssl ecparam -genkey -name
prime256v1 -noout  key.pem; ls -l key.pem | sed '/ 227 /d'` !=  x ];
then echo; cat key.pem;else echo -n .; fi; done

-BEGIN EC PRIVATE KEY-
MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D
AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8
fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY
-END EC PRIVATE KEY-

...

Conforming to the standards the EC private key has always a fixed length,
defined by the group order.

Regards,
Ann.




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


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

Re: [openssl-users] [openssl-dev] [openssl.org #3726] Cocoapods install BUG

[Erwann Abalea]

It seems all the tarballs have disappeared.

--
Erwann ABALEA

Le 02/03/2015 18:06, Alex Sklyar via RT a écrit :

Hello guys. There is a issue with openssl pod installing with cocoapods tool. 
The URL «https://www.openssl.org/source/openssl-1.0.2.tar.gz» is dead.



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

Re: [openssl-users] S/MIME mime type application/octet-stream

[Erwann Abalea]

This is my first attempt ever at magic(5) voodoo:

0 byte 0x30
0x01 byte 0x80
0x02 string \x06\x09\x2a\x86\x48\x86\xf7\x0d\x01\x07\x02 Indefinite 
length pkcs7-signedData

!:mime application/pkcs7
0x02 string \x06\x09\x2a\x86\x48\x86\xf7\x0d\x01\x07\x03 Indefinite 
length pkcs7-envelopedData

!:mime application/pkcs7
0x03 search/10 \x06\x09\x2a\x86\x48\x86\xf7\x0d\x01\x07\x02 Definite 
length pkcs7-signedData

!:mime application/pkcs7
0x03 search/10 \x06\x09\x2a\x86\x48\x86\xf7\x0d\x01\x07\x03 Definite 
length pkcs7-envelopedData

!:mime application/pkcs7

I'm pretty sure it's ugly, suboptimal, and whatever. It WORKSFORME, on 
an indefinite length signature as well as the corresponding definite one 
recreated by OpenSSL.

I haven't contempted the idea of parsing ASN.1/BER in magic(5) parlance.

--
Erwann ABALEA

Le 06/11/2014 17:24, Jan Hejl a écrit :

Hello,

i found that the file command detects S/MIME attachment (smime.p7s) 
within a signed email as an application/octet-stream insted of 
application/pkcs7. Author of the file tool tells that it's impossible 
to detect application/pkcs7. Does anybody knows why?


Thank you
Jan



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] OpenSSL X509 Parse Error with Elliptice curve Public Key

[Erwann Abalea]

Your EC point is on the brainpoolP256r1 curve. This curve isn't 
supported by OpenSSL (yet).


--
Erwann ABALEA

Le 20/10/2014 10:16, Harakiri a écrit :

Im getting the following error

using  openssl x509 -inform DER -in cms_cert.der -text
140026491385512:error:100D7010:elliptic curve routines:ECKEY_PUB_DECODE:EC
lib:ec_ameth.c:206:
140026491385512:error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public
key decode error:x_pubkey.c:164:

I found a message stating that:

Your public key parameter field is set to NULL. It must either be an OID
to name the curve, or explicit parameters.


Does this apply to the pkey i have attached to this message too ?

Windows does not complain about the key tho.

Is the key RFC conform (its not mine, but i have to validate it) ?

Thanks

Re: [openssl-users] Is it possible to disable SSLv3 for all openssl-enabled applications via settings in openssl.cnf?

[Erwann Abalea]

Would you like all your OpenSSL-enabled applications to be configured 
all the same, with the same protocols and same ciphersuites?


--
Erwann ABALEA

Le 15/10/2014 23:56, Todd Pfaff a écrit :

I'd like to be able to disable SSLv3 for all openssl-enabled applications
in a single configuration file if possible, so that this doesn't have to
be done for each application.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Query reg multiple CA-Cert in list with same subject

[Erwann Abalea]

Bonjour,

No need to include openssl-dev here.
If A1 and A2 have the same subject, then they are 2 certificates for the 
same CA. Therefore, your gateway is right in testing A1 first.
However, if your software is correctly configured, it should also test 
A2. That's what OpenSSL does when given a set of CA certificates.


If your gateway software is a commercial software, please report this 
misbehaviour to the vendor.


--
Erwann ABALEA

Le 10/06/2014 09:08, Mukesh Yadav a écrit :

Hi,

I have a query for Ca-Cert list.
If at gateway we have configured two CA-certs A1 and A2 both having 
same subject and content except time-stamp of generation.


If peer sends Cert matching to A2, gateway tries to validate it with 
A1(subject being same and configured first in list) and validation fails.


1. is there a way to avoid addition of cert in store if subject and 
all contents are same except timestamp generation.
2. Or if not 1st, is there way to validate incoming cert with both 
cert configured in store.



Thanks

Re: [openssl-users] OpenSSL on Mac

[Erwann Abalea]

Darwinports.

--
Erwann ABALEA

Le 31/03/2014 21:18, Landen Landens a écrit :
My Mac still has OpenSSL 0.9.8.  How may I update this to the latest 
stable version?


I believe the latest stable version is at least 1.0.01


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: OpenSSL PKI Tutorial updated

[Erwann Abalea]

Le 27/03/2014 11:14, Jeffrey Walton a écrit :

On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek ste...@epy.co.at wrote:

On 25.03.2014, at 17:44, Zack Williams wrote:


...
3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?

Pathlen is not used on root CA certs. ...

RFC 5280 might disagree. For example, section 6.1.2 (k):

   (k)  max_path_length:  this integer is initialized to n, is
decremented for each non-self-issued certificate in the path,
and may be reduced to the value in the path length constraint
field within the basic constraints extension of a CA
certificate.


No disagreement here.
Initial value of the max_path_len is set to the length of certificate 
chain, and it's not taken from the BasicConstraints extension of the 
trust anchor. The rest of the phrase (after the first comma) explains 
how it will decrease, but it's detailed later in the algo.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: OpenSSL PKI Tutorial updated

[Erwann Abalea]

Le 25/03/2014 23:08, Zack Williams a écrit :

On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea
erwann.aba...@keynectis.com wrote:

2. I couldn't figure out what the [additional_oids] section of the
Expert example's root-ca.conf file is for - either through research or
going through the commit history.  Could you elaborate on what that
accomplishes?

https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html

The OIDs are used in the CertificatePolicies extension of a subordinate CA
of this root CA.
For a policyId to be acceptable for an end-user certificate, this same
policyId (or the special value anyPolicy) MUST be present in all CAs between
this end-user cert and the root CA. The root CA is special in that it
doesn't need to contain any CertificatePolicies extension.

So these are used to group or link the certificate chain together?


No, it's about authorized uses of certificates.

Certificate policy is defined by the X.509 recommendation as:
A named set of rules that indicates the applicability of a certificate 
to a particular community and/or class of application with common 
security requirements. For example, a particular certificate policy 
might indicate applicability of a type of certificate to the 
authentication of electronic data interchange transactions for the 
trading of goods within a given price range.


What identifies a specific CP is a policyId, and it's represented by an 
OID. Having a policyId declared or not in a CA allows for its issuing CA 
to allow or deny the right of this subCA to deliver certificates that 
can be used in accordance to this CP.




Is there guidance for generating and naming this OID? Given an OID in this form:

1.3.6.1.4.1.X.Y.Z

I'm assuming that you would register the top level number (X) with the
IANA (or other appropriate issuing body), but is there guidance to
setting Y and Z, which are 7 and 8 or 9 respectively in the Expert
example?


No guidance necessary, everyone is free to shape its OID space as wanted.


3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?

Because it's not used by the standardized validation algorithm (RFC5280
section 6, X.509 section 10).

I looked through RFC5280 section 6.1.4 (m), and it appears that
setting the pathLen would apply to the Root CA, and would cause
section (l) to fail on CA's created beyond the depth specified.  Am I
interpreting the RFC incorrectly?


You overlooked this, in 6.1:

[...]
   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

  (a)  for all x in {1, ..., n-1}, the subject of certificate x is
   the issuer of certificate x+1;

  (b)  certificate 1 is issued by the trust anchor;

  (c)  certificate n is the certificate to be validated (i.e., the
   target certificate); and

  (d)  for all x in {1, ..., n}, the certificate was valid at the
   time in question.
[...]

Point (b) is important.

Now look at 6.1.2 (Initialization), point (k):
-
  (k)  max_path_length:  this integer is initialized to n, is
   decremented for each non-self-issued certificate in the path,
   and may be reduced to the value in the path length constraint
   field within the basic constraints extension of a CA
   certificate.
-
and you'll understand that any BasicConstraints:pathLenConstraint set in 
the Trust Anchor isn't used at all.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: OpenSSL PKI Tutorial updated

[Erwann Abalea]

Le 25/03/2014 17:44, Zack Williams a écrit :

On Fri, Mar 21, 2014 at 12:25 AM, Stefan H. Holek ste...@epy.co.at wrote:

I have updated the OpenSSL PKI Tutorial at Read the Docs. The tutorial provides 
three complete PKI examples you can play through and the prettiest 
configuration files this side of Neptune. Check it out!

https://pki-tutorial.readthedocs.org/

This is really awesome.   I've been trying to make sense of the config
files for cert generation and align to best practices (when I can find
them), and having good documentation is great.

A few questions:

1. Is there a reason you're not using SHA-256 hash by default - it
appears that SHA1 is being recommended against currently:
http://www.digicert.com/sha-2-ssl-certificates.htm


Good point.


2. I couldn't figure out what the [additional_oids] section of the
Expert example's root-ca.conf file is for - either through research or
going through the commit history.  Could you elaborate on what that
accomplishes?

https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html


The OIDs are used in the CertificatePolicies extension of a subordinate 
CA of this root CA.
For a policyId to be acceptable for an end-user certificate, this same 
policyId (or the special value anyPolicy) MUST be present in all CAs 
between this end-user cert and the root CA. The root CA is special in 
that it doesn't need to contain any CertificatePolicies extension.



3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?


Because it's not used by the standardized validation algorithm (RFC5280 
section 6, X.509 section 10).

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] openssl-0.9.8j has problem with Google HTTPS using SSLv3

[Erwann Abalea]

Bonjour,

It seems OpenSSL 0.9.8j doesn't like receiving a New Session Ticket 
message over an SSLv3 session, even when it sends an empty session 
ticket in its ClientHello message.


Possible solutions:
  -tls1 instead of -ssl3
  add -no_ticket

--
Erwann ABALEA

Le 21/02/2014 11:03, Lvqier a écrit :

Hi Team,

I have post the problem I meet on stackoverflow.com: 
http://stackoverflow.com/questions/21929664/openssl-0-9-8j-can-not-connect-to-google-https-services-using-sslv3 



It might be a bug of openssl, could you help to find out where is wrong ?

Thank you!

Re: [openssl-users] MODSSL: RFC 2560

[Erwann Abalea]

Bonsoir,

Le 14/01/2014 19:44, socket a écrit :

Hey all, I am wondering if anyone here could point me in the right direction
or even assist with a problem I have having.

According to RFC 2560:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
  *  -- a Trusted Responder whose public key is trusted by the requester*
-- a CA Designated Responder (Authorized Responder) who holds a
   specially marked certificate issued directly by the CA, indicating
   that the responder may issue OCSP responses for that CA

[...]
I am able to successfully validate cc1 and any other client certificates
issued from ia1.  However, when I try to use cc2, I get the following error:
*SSL Library Error: error:27069070:OCSP routines:OCSP_basic_verify:root ca
not trusted*

Looking at a post in the past:
http://openssl.6102.n7.nabble.com/OCSP-basic-verify-root-ca-not-trusted-td24451.html

it seems that the RFC should allow me to explicitly declare a trusted
responder certificate for the client machine (in this case the client is the
httpd 2.4 server). However it doesn't seem that mod_ssl allows me to declare
this.

I would like to know:
Am i right in thinking I should be able to do this?


That's a strange question. You *want* to do this, so you have to find a 
software that allows this. If you randomly chose a software that 
doesn't, you may have some hard time explaining that this software 
*should* allow this.



Who currently supports mod_ssl and how would i present a change request?


mod_ssl is part of Apache HTTP server, so it's fully maintained by the 
Apache foundation, you should visit 
http://projects.apache.org/projects/http_server.html



Does mod_ssl currently support this feature unbenounced to me?


It seems it doesn't, but I only looked at the documentation, not the 
source code.



if not, would anyone be willing to teach me how to modify mod_ssl to support
something like: *'SSLOCSPTrusted_responder
/etc/pki/tls/certs/trustedresponder.pem'*


You'll have to learn how Apache modules are coded, add a configuration 
directive for mod_ssl, add a field in this module's config structure to 
hold the VA file, and use whatever this field contains when OCSP 
validation happens (that's where OpenSSL comes in).
Optionally, you may find interesting to contribute your enhancement back 
to Apache httpd, or you'll have to apply your patch each time you want 
to upgrade your httpd version for security reasons.


I bought The Apache Modules Book, by Nick Kew, and found it helpful 
for my projects. Working with OpenSSL since its very beginning helps a lot.



Other applications like openssl and corestreet desktop validation client
allow you to explicitly configure a trusted responder cert.
eg: openssl ocsp -CAfile rca2-issuer ia2 -cert cc2 -VAfile ocsp1 -url
http://rsp.domain.com:80


That means the PKI core (OpenSSL) is able to do what you're looking for. 
That's a good start.

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Erwann Abalea]

Le 13/12/2013 19:30, Walter H. a écrit :

On 12.12.2013 14:16, Erwann Abalea wrote:

It's not strange.
You removed the RSA-* from client side, the result is that the server 
can't match anything in common between what the client proposed and 
what the server accepts. The error you get has been sent by the server.



The server is capable of ciphers DHE-* and others;
the list is quite longer than the avaiable ciphers of the client ...,
 so I think this is quite strange ...


The ClientHello message will show what ciphersuite is proposed by the 
client.

You'll have to match it with what the server is willing to accept.


openssl ciphers -V

shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
the site https://cc.dcsec.uni-hannover.de/ shows this: 
ECDHE-ECDSA-3DES-EDE-SHA


are these the same cipher suites but two confusing names?


I'd say yes, but what is really exchanged is a list of 16 bits numbers, 
not names.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Erwann Abalea]

Don't regret it, it wasn't that bad ;)

--
Erwann ABALEA

Le 13/12/2013 20:39, andrew cooke a écrit :

sorry, that was a bad joke i now regret sending.  andrew

On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote:

it dpends how many characters differ when sorted.

in this case:

ECDHE-ECDSA-DES-CBC3-SHA - 3AABDDDHHSSS
* *** **
ECDHE-ECDSA-3DES-EDE-SHA - 3AACCEEHHSSS

you can see (marked by *) that 6 characters don't match.

now 6 is a triangular number, but the length of the entire cipher suite is 24,
which isn't triangule (the closest is 21).

so they're only going to inter-operate on tuesdays.

andrew


On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote:

On 12.12.2013 14:16, Erwann Abalea wrote:

It's not strange.
You removed the RSA-* from client side, the result is that the
server can't match anything in common between what the client
proposed and what the server accepts. The error you get has been
sent by the server.


The server is capable of ciphers DHE-* and others;
the list is quite longer than the avaiable ciphers of the client ...,
  so I think this is quite strange ...

openssl ciphers -V

shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
the site https://cc.dcsec.uni-hannover.de/ shows this:
ECDHE-ECDSA-3DES-EDE-SHA

are these the same cipher suites but two confusing names?

Walter






__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Erwann Abalea]

It's not strange.
You removed the RSA-* from client side, the result is that the server 
can't match anything in common between what the client proposed and what 
the server accepts. The error you get has been sent by the server.


--
Erwann ABALEA

Le 11/12/2013 22:34, Walter H. a écrit :

Hello,

Thanks for your reply;

Very strange in FF

when I disable the use of the RSA-* Ciphersuites in FF, then I get the 
following error


Secure Connection failed
Cannot communicate securely with peer: no common encryption algorithm(s).
(Error code: ssl_error_no_cypher_overlap)

the certificate is mimicked by the origin certificate -
look on the origin certificate of https://www.google.nl

Thanks,
Walter

On 11.12.2013 20:56, Erwann Abalea wrote:

Bonjour,

The certificate specifies digitalSignature as its sole key usage.
That means the certified key can only be used to sign data, and not 
perform any decrypt operation.


If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite, 
that's OK because the server's RSA private key will then be used to 
sign the (EC)DHE parameters and ephemeral public key, and the key 
exchange mechanism will be based on (EC)DHE.


But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or 
anything similar using RSA as the key exchange mechanism, it won't 
work because the private key will then be used to decrypt the 
premaster secret.


Only NSS checks this, so Firefox under any OS, and Chrome under Linux.

If you want to get rid of this message, choose either one of:
 - create a new certificate for your server with 
keyUsage=digitalSignature+keyEncipherment
 - setup your server to only allow (EC)DHE key exchange mechanisms, 
by tweaking its acceptable ciphersuites








__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Erwann Abalea]

Bonjour,

The certificate specifies digitalSignature as its sole key usage.
That means the certified key can only be used to sign data, and not 
perform any decrypt operation.


If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite, 
that's OK because the server's RSA private key will then be used to sign 
the (EC)DHE parameters and ephemeral public key, and the key exchange 
mechanism will be based on (EC)DHE.


But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or anything 
similar using RSA as the key exchange mechanism, it won't work because 
the private key will then be used to decrypt the premaster secret.


Only NSS checks this, so Firefox under any OS, and Chrome under Linux.

If you want to get rid of this message, choose either one of:
 - create a new certificate for your server with 
keyUsage=digitalSignature+keyEncipherment
 - setup your server to only allow (EC)DHE key exchange mechanisms, by 
tweaking its acceptable ciphersuites


--
Erwann ABALEA

Le 11/12/2013 20:29, Walter H. a écrit :
[...]
can please someone tell me why I get in FF (in an old 3.6 and in an 
relatively actual one 24.2esr)


This Connection is Untrusted

www.google.nl uses an invalid security certificate.
The certificate is not trusted because it was issued by an invalid CA 
certificate.

(Error code: sec_error_inadequate_key_usage)

[...]

-BEGIN CERTIFICATE-
MIIFPTCCBKagAwIBAgIUPXX9MOspr8vFn1yK/75ufujyNyMwDQYJKoZIhvcNAQEF
BQAwRzELMAkGA1UEBhMCLS0xEDAOBgNVBAoTB1NvbWVPcmcxFDASBgNVBAsTC1Nv
bWVPcmdVbml0MRAwDgYDVQQDEwdSb290IENBMB4XDTEzMTEyMDE1MTMzNloXDTE0
MDMyMDAwMDAwMFowZjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
FjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2dsZSBJbmMxFTAT
BgNVBAMMDCouZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
9Rn9qpNvO67yqcBIcmbcosnL5egvWbLyxzCsoIpk6s6IhqyDuLW8NW6gGXAo7tT9
BwF14xZnVVvFj7Oq4Nrl7bARIjvf9YEOo4uvypfMhIckVV0XB1TLs8fXUgBOCCc2
lzYEqqphzaGnMR2SAlexj2sQalb35RsianHNCgw/DEMCAwEAAaOCAwUwggMBMIIC
wwYDVR0RBIICujCCAraCDCouZ29vZ2xlLmNvbYINKi5hbmRyb2lkLmNvbYIWKi5h
cHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29nbGUuY29tghYqLmdvb2ds
ZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYYILKi5nb29nbGUuY2yCDiouZ29v
Z2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi5nb29nbGUuY28udWuCDyouZ29v
Z2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg8qLmdvb2dsZS5jb20uYnKCDyou
Z29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm14gg8qLmdvb2dsZS5jb20udHKC
DyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZGWCCyouZ29vZ2xlLmVzggsqLmdv
b2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2xlLml0ggsqLmdvb2dsZS5ubIIL
Ki5nb29nbGUucGyCCyouZ29vZ2xlLnB0gg8qLmdvb2dsZWFwaXMuY26CFCouZ29v
Z2xlY29tbWVyY2UuY29tgg0qLmdzdGF0aWMuY29tggwqLnVyY2hpbi5jb22CECou
dXJsLmdvb2dsZS5jb22CFioueW91dHViZS1ub2Nvb2tpZS5jb22CDSoueW91dHVi
ZS5jb22CFioueW91dHViZWVkdWNhdGlvbi5jb22CCyoueXRpbWcuY29tggthbmRy
b2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb29nbGUtYW5hbHl0aWNzLmNvbYIKZ29v
Z2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY29tggp1cmNoaW4uY29tggh5b3V0dS5i
ZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29tMAsGA1UdDwQEAwIH
gDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQA4xQFls1FpUScdCmifTkWCrjNrgUCbL56im1/9vSqM
P8IplBopOikz3VnxBsyUVaR/yt8zzm158zYdIpA/rOX0WukwO4pAUoi6aw6Q+FoD
ZG+3Qe0b7a22Mqgl45OlfljrAMfouvapjx8OA9COSM/2k2TtRnlEy7D929O2H6J6
CQ==
-END CERTIFICATE-


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: Bad OIDs

[Erwann Abalea]

Le 28/11/2013 22:18, Rob Stradling a écrit :

On 28/11/13 15:14, Erwann Abalea wrote:

How nice, they're asking for a self-signed certificate to include a
specific EKU to indicate it's a Trust Anchor, and the OID used for this
has never been allocated. Crazy.


It's crazier than that.  RFC5906 seems to think it can put a string 
into the EKU extension rather than OID(s)!  Appendix J says...

 Extended Key Usage.  This field...contains the string Private if
  the certificate is designated private or the string trustRoot if
  it is designated trusted...


And the reference code uses the strings Trust Root and Private.
I subscribed and sent a series of questions on this yesterday, it's 
still pending for moderation.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: Bad OIDs

[Erwann Abalea]

Le 29/11/2013 16:25, Dr. Stephen Henson a écrit :

On Thu, Nov 28, 2013, Erwann Abalea wrote:


How nice, they're asking for a self-signed certificate to include a
specific EKU to indicate it's a Trust Anchor, and the OID used for
this has never been allocated. Crazy.

I just looked at OpenSSL's objects.txt database, and found some OIDs
that need some change:

id-pkix-OCSP 8: extendedStatus: Extended OCSP Status
should be id-pkix-ocsp-pref-sig-algs (RFC6960).

id-pkix-OCSP 9: valid
should be id-pkix-ocsp-extended-revoke (RFC6960).

id-pkix-OCSP 10   : path
id-pkix-OCSP 11   : trustRoot : Trust Root
have never been defined by PKIX.

Weird.. I checked the OpenSSL OID history and those have been about since the
dawn of time... well July 2000 at any rate. They were added by Richard when
he created the scripts that handle objects.txt, no idea where they actually
came from.


Some of them seem to have been mentioned in old drafts. 
draft-ietf-pkix-ocsp-valid-00 mentions 2 new OIDs: 
id-pkix-ocsp-valid-req and id-pkix-ocsp-valid-rsp. 
draft-ietf-pkix-ocsp-path-00 similarly mentions id-pkix-ocsp-path-req 
and id-pkix-ocsp-path-rsp.
I have no idea where this trustRoot comes from; PHB then at Verisign 
published draft-ietf-pkix-ocspx-00 with more extensions, but all those 
OIDs were on a branch below id-pkix-ocspx (which was a descendant of 
id-pkix-ocsp); he also describe a structure named TrustRoot and a 
corresponding id-pkix-ocspx-root OID for it, and similarly with 
ExtendedStatus and OID id-pkix-ocspx-support.
But all those drafts were abandoned (after their version 00) and the 
OIDs were never reserved.



Changing OIDs in the table is problematical. If anything uses them it could
break them in all sorts of ways. The NID_* entries would change and text based
lookup would no longer work.


The reference ntp server uses that trustRoot one, in fact. And as Rob 
pointed, it compares the text representation of this OID with Trust 
Root (the long form) to check if the certificate is trusted or not. 
Similarly, if it finds a certificate with 1.3.6.1.4 OID (IANA private) 
as a EKU, the long form will be Private, and ntp will declare this 
certificate as private+trusted.


I'm not sure OpenSSL should be bound to keep OIDs that were never 
formally allocated and are incorrectly used. If anything relying on 
those breaks, it's either experimental, or badly written, or improperly 
specified. Not OpenSSL's fault.


Anyway, 8 and 9 should really be changed.

Re: [openssl-users] Re: Bad OIDs

[Erwann Abalea]

Le 29/11/2013 17:53, Erwann Abalea a écrit :

Le 29/11/2013 16:25, Dr. Stephen Henson a écrit :


Changing OIDs in the table is problematical. If anything uses them it could
break them in all sorts of ways. The NID_* entries would change and text based
lookup would no longer work.


The reference ntp server uses that trustRoot one, in fact. And as Rob 
pointed, it compares the text representation of this OID with Trust 
Root (the long form) to check if the certificate is trusted or not. 
Similarly, if it finds a certificate with 1.3.6.1.4 OID (IANA private) 
as a EKU, the long form will be Private, and ntp will declare this 
certificate as private+trusted.


Technically, the NID_* version of those OIDs are not used by ntpd. For 
each extension found, an X509V3_EXT_print() is done on the extension, 
the result is strcmp() with Trust Root and/or Private, and internal 
flags are set.


I'm not sure this code works anyway.

Bad OIDs (was: Re: Verification of a x509 certificate signature)

[Erwann Abalea]

How nice, they're asking for a self-signed certificate to include a 
specific EKU to indicate it's a Trust Anchor, and the OID used for this 
has never been allocated. Crazy.


I just looked at OpenSSL's objects.txt database, and found some OIDs 
that need some change:


id-pkix-OCSP 8: extendedStatus: Extended OCSP Status
should be id-pkix-ocsp-pref-sig-algs (RFC6960).

id-pkix-OCSP 9: valid
should be id-pkix-ocsp-extended-revoke (RFC6960).

id-pkix-OCSP 10   : path
id-pkix-OCSP 11   : trustRoot : Trust Root
have never been defined by PKIX.

RFC5906 uses a trustRoot EKU, without any OID being proposed or 
referenced. Your certificate includes the later one in the EKU extension.


--
Erwann ABALEA

Le 28/11/2013 14:26, Dereck Hurtubise a écrit :
It is NTP indicating that this certificate is held by a supposed 
trusted root (authority).
This is NTP's way of figuring out if the certificate of the 
subject/issuer should be trusted or not.


So they misuse X509 extensions for their own purposes.

This alone is not enough.
So they also implement a challenge/response scheme that they do after 
the certificates are verified.


Read RFC 5906 (autokey) on the CERT message/exchange for more 
information and why they do this.
The Trust Root is used in the identity exchange scheme after the CERT 
exchange. Also in the RFC.



On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.info 
mailto:walte...@mathemainzel.info wrote:


Hi,

On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote:
 X509v3 Extended Key Usage:
 Trust Root

what is this strange?
'Trust Root' as Extended Key Usage?

__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
mailto:openssl-users@openssl.org
Automated List Manager majord...@openssl.org
mailto:majord...@openssl.org

Re: [openssl-users] Need to send CN attribute in TeletexString/T61String format for ASN1DN Id and certificate

[Erwann Abalea]

OpenSSL supports T61String data type, but doesn't provide any conversion 
helper.
You should avoid T61String if you can, the T.61 standard that defined it 
has been withdrawn before 1993.
So unless you're playing with antique software that can't work with an 
UTF8 string, prefer UTF8String.


--
Erwann ABALEA

Le 25/11/2013 15:15, Sanjay Kumar (sanjaku5) a écrit :


Hi,

   We need to send CN attribute in TeletexString format for ASN1DN Id 
and certificate.


Does openssl support for TeletexString/ T61String(T61String, an 
arbitrary string of T.61 (eight-bit) characters.) ?


What are function user to read the T61String format value ?

Could someone help me with list of functions used for T61String ?

Thanks,

Sanjay

Re: [openssl-users] CA certificate bundle bogus certs

[Erwann Abalea]

Bonjour,

Le 25/11/2013 17:14, Sassan Panahinejad a écrit :
I am dealing with a CA certificate bundle, similar to this one: 
https://github.com/twitter/secureheaders/blob/master/config/curl-ca-bundle.crt, 
like the example, the one I am dealing with was automatically 
generated from mozilla's certdata.txt.


Consider the certificate labelled Bogus live.com http://live.com. 
Now I know from some searching that this certificate is intended to 
block a bad certificate, but I don't know how this works in an openssl 
cert bundle. I am concerned that perhaps the conversion from the 
format used by mozilla has lead to the certificate being included as a 
trusted cert instead of an explicitly untrusted one.


Note that there are no other associated files (eg: blacklist.txt) (in 
either the example given, or the file I am dealing with).


There's no real question in this post.

The author of the script used to create a CA bundle from the Mozilla 
root store only took the certificates from this Mozilla root store, 
without the associated permissions. This script is incomplete, and the 
resulting output should NOT be used.
Therefore, you'll find as a result explicitely distrusted certificates, 
such as bogus live.com cert, but also DigiNotar CA certificates, 
MD5-collision CA, other bogus certs (gmail, yahoo, etc), and CA 
certificates not trusted for SSL use.


Don't use that file, at all.

--
Erwann ABALEA

Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?

[Erwann Abalea]

Bonjour,

Le 13/11/2013 11:35, Igor Sverkos a écrit :

Hi,

please see the following certificate:

-BEGIN CERTIFICATE-
MIIEbTCCA1WgAwIBAgICLgAwDQYJKoZIhvcNAQEFBQAwQDELMAkGA1UEBhMCVVMx
[...]
uKnvqzQP10A7f3PBsGYRA2DCeMDavaEoizJnNyjCOQx4
-END CERTIFICATE-

It seems to be a valid certificate for OpenSSL, right?


OpenSSL can parse it, yes.


But it isn't, see the OID 2.5.4.8 (stateOrProvinceName):

0b0: 310b 3009 0603 5504 0613 0244 4531 0930 1.0...UDE1.0
0c0: 0706 0355 0408 1300 3112 3010 0603 5504 ...U1.0...U.
0d0: 0713 094b 6172 6c73 7275 6865 3114 3012 ...Karlsruhe1.0.

Octal sequence 3109300706035504081300..

The value has zero length. According to RFC 3280, which defines
X.509 certficates, these entries, if they exist, must not have
an empty value.


RFC5280 doesn't define X.509 certificates, it defines a profile of X.509 
certificates. X.509 defines X.509 certificates.


Reading X.520 shows that the DirectoryString type disallows 0-sized 
elements. So you're right, this isn't a valid X.509 certificate.




I found this problem while using FileZilla (which uses GnuTLS),
which denied to connect to a host using such a (broken) certificate:

  Error: GnuTLS error -71 in gnutls_x509_crt_get_dn: ASN1 parser: 
Generic parsing error.
  Error: Could not get distinguished name of certificate subject, 
gnutls_x509_get_dn failed

  Error: Could not connect to server


Following gnutls code is hard, but I think I tracked down to the faulty 
function. String objects are decoded as OCTETSTRING ones, and the 
ASN.1/DER parser can't parse OCTETSTRING objects whose length is = 0. 
The error returned is ASN1_GENERIC_ERROR.




For further details please see:
https://forum.filezilla-project.org/viewtopic.php?f=2t=31046

I am wondering why OpenSSL doesn't complain.


Because it has a more tolerant parser.

GNUtls is primitive in some aspects, DN parsing is one of them.
Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL.

Re: [openssl-users] Re: OpenSSL doesn't treat RFC 3280 validations as an error?

[Erwann Abalea]

This is taken from X.520/RFC5280:
   DirectoryString ::= CHOICE {
 teletexString   TeletexString (SIZE (1..MAX)),
 printableString PrintableString (SIZE (1..MAX)),
 universalString UniversalString (SIZE (1..MAX)),
 utf8String  UTF8String (SIZE (1..MAX)),
 bmpString   BMPString (SIZE (1..MAX)) }

Nearly every attribute type is encoded as a DirectoryString. An empty 
element doesn't respect the size constraint, so is invalid.


--
Erwann ABALEA

Le 13/11/2013 11:48, Ben Laurie a écrit :

On 13 November 2013 10:35, Igor Sverkos igor.sver...@googlemail.com wrote:

According to RFC 3280, which defines
X.509 certficates, these entries, if they exist, must not have
an empty value.

FWIW, RFC 3280 has been obsoleted by RFC 5280.

I couldn't find where it said this in RFC 5280. Pointer?


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?

[Erwann Abalea]

Le 13/11/2013 13:30, Igor Sverkos a écrit :

Hello,

thank you for your response. There's one thing in your reply I don't 
understand:


Erwann Abalea wrote:
 It seems to be a valid certificate for OpenSSL, right?

 OpenSSL can parse it, yes.

 [...]

 Reading X.520 shows that the DirectoryString type disallows 0-sized
 elements. So you're right, this isn't a valid X.509 certificate.

 [...]

 GNUtls is primitive in some aspects, DN parsing is one of them.
 Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL.

If it isn't a valid X.509 certificate as you agreed, shouldn't openssl
complain when I verify/establish a connection using AUTH TLS which 
will use

this certificate?


Well. It could be very strict. Would it solve the problem you have with 
gnutls? No.

Does this tolerance have any security impact? No.


So for me it is not a question about tolerance like you said OpenSSL's
ASN1 parser is more tolerant than GnuTLS (it uses libtasn1 BTW): If the
certificate is invalid, OpenSSL should tell it and verify shouldn't pass.


Verifying the presented certificate with certtool from gnutls version 
3.0.11 on my Ubuntu 13.10 works (haven't checked if they have special 
patches for this).
Place your certificate+issuingCA+rootCA in a file, and run certtool -e 
--infile allcerts.pem.

Re: [openssl-users] Is aesni-intel module required for openssl

[Erwann Abalea]

The Linux kernel module isn't necessary for OpenSSL.

--
Erwann ABALEA

Le 07/11/2013 06:48, sarav.sars a écrit :

Is it necessary to load aesni-intel module like 'modprobe aesni-intel' ?
Loading this module makes no difference in openssl speed output.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: connection problem with the version 1.0.1e

[Erwann Abalea]

Le 11/10/2013 19:57, nehakochar a écrit :

Erwann ABALEA wrote

The server and client are both compliant.

With the first command, you tell the client to use TLS1.0 only. No more,
no less. The server is ok with it, and both negociate TLS1.0.
With the second command, you tell the client to use TLS1.2 only, again
no more no less. The server receives a TLS1.2 negociation, replies with
a TLS1.0 server hello message, and the client refuses it, cleanly
(because you told it to do so).

If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2
-no_ssl3 options instead.

In my case, SSL client is using OpenSSL 1.0.1e. I do not which version is
the server using, but must be an older version. When the client is sending
ClientHello with version 0x0303 (TLS1.2), the server does not respond at
all. In which versions of OpenSSL is the above server behavior expected?


I used the same server you're talking about earlier in the thread:
emea.webservices.travelport.com:443

And this server behaves as I wrote, correctly, sending a TLS1.0 
ServerHello, refused by the client.


Are you talking about another one?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: connection problem with the version 1.0.1e

[Erwann Abalea]

Bonjour,

Le 11/10/2013 03:35, nehakochar a écrit :

Rajesh Malepati wrote

On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;
kirpit@
gt; wrote:

The server doesn't seem to care to respond to clients supporting TLS 1.2

ok:
  openssl s_client -tls1 -connect emea.webservices.travelport.com:443

no reply:
openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443

such servers should be beaten to pulp.

Hi,
I ran into the same problem and then came across this thread. According to
http://tools.ietf.org/html/rfc5246#appendix-E:
   A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version.  If the server does not support this
version, it will respond with a ServerHello containing an older
version number.

Why then the server isn't responding at all to the Client Hello for TLS1.2?
Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
need to be fixed as it is not compliant with the RFC.


The server and client are both compliant.

With the first command, you tell the client to use TLS1.0 only. No more, 
no less. The server is ok with it, and both negociate TLS1.0.
With the second command, you tell the client to use TLS1.2 only, again 
no more no less. The server receives a TLS1.2 negociation, replies with 
a TLS1.0 server hello message, and the client refuses it, cleanly 
(because you told it to do so).


If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2 
-no_ssl3 options instead.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Updating key size - security related questions

[Erwann Abalea]

Bonjour,

Le 10/10/2013 18:29, int0...@safe-mail.net a écrit :

Hi,

I've been asking this on the OpenVPN mailinglist, but didn't get an answer so 
far. Therefore I hope you can help me.
We use OpenVPN in our company with the default cipher suite, which should be: 
DHE_RSA_BF_CBC_SHA

So RSA is used for authentication, Blowfish in CBC mode for symmetric 
encryption. The keys for Blowfish are derived from ephermal Diffie-Hellman and 
changed every hour.


Make sure you don't encrypt more than 2^35 bytes with the same BF key. 
Otherwise, you have an additional problem.



We use a keysize of 1024 bit for RSA and therefore a modulus of 1024 bit for 
Diffie-Hellman (OpenVPN uses the Easy RSA scripts. These scripts use a variable 
KEY_SIZE when the Diffie-Hellman parameter or the RSA keys ar built. This 
variable is set to 1024). Furthermore we use a self-signed CA.

Some days ago I recommended to update the key size to 2048 bit, mainly because 
some sources say 1024 bit aren't enough anymore. Because quite a lot of our 
staff uses OpenVPN, they asked me, if it is possible, to not update all keys at 
once - but only issue user certs with 2048 from now on for new OpenVPN users 
(and leave the old ones in places for later update).
The process of doing that should look like that:

a) Change variable KEY_SIZE used in Easy RSA scripts from 1024 to 2048 (bit).
b) Create new Diffie-Hellman params with the Easy RSA build-dh script (will 
create the params with 2048 bit modulus).
c) Update the OpenVPN server config with the path of the new Diffie-Hellman 
param file.

Now here are my concerns and why _I_ think, that is a bad idea:
If I do it like that, new users would get 2048 bit keys/cert as requested by the company. But theses certs would still 
be signed by our self signed CA which still uses the old 1024 bit key/cert. Given that an attacker has enough computing 
power, he could factorize n (from the pub key in the CA cert) to get p and q. With 
that he would have our CA's private key, being able to create a faked server cert and sign it with the CA key. With 
that server certificate the attacker could launch a man in the middle attack. That would mean: Authentication via RSA 
would be leveraged.


As in broken? Yes.


So my question are:
I. Am I right, or is that rubbish?


You're right. On the other side, how powerful are your opponents? 1024 
bits factorization isn't an easy task, it requires a large amount of 
money. Large isn't a precise number, for sure; I'd place the lower 
limit at 1M$. But don't trust me.



II. Is an attacker able to get the CA cert at all? It looks as if during TLS 
handshake only the User certificate and the Server certificates are 
transmitted, but not the CA cert.


A public key isn't designed to be kept private. Given some certificates 
signed by the same private key, the modulus of the signer key can be 
guessed.

Consider your CA modulus to be public.


III. To complicate things a bit more:
OpenVPN supports a so called tls-auth directive which takes a 160 bit key. 
According to the OpenVPN documentation this key is used to generate a HMAC over every 
packet during TLS handshake (and append it?). It looks as if this is not part of TLS 
itself, but a modified implementation of TLS. They say, that without the key, not even 
the handshake would work.
So my last question is:
If the CA cert, can be requested from the OpenVPN Server somehow, that wouldn't 
work anymore, if such a key is used. Is that correct?


It depends on how this key is used. I don't have any opinion on this point.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: adding certificate policies extension in CSR

[Erwann Abalea]

The requestor is allowed to ask for any extension it wants.
The CA will do its job, ignore those requested extensions, and place the 
good ones in the certificate. It can also change the subject name 
contained in the certificate.


--
Erwann ABALEA

Le 09/09/2013 11:21, phildoch a écrit :

Oh I see. Can you point to a documentation where it is defined which
extensions a certificate requestor is allowed to add and which should be
added by the CA only?
  Thanks.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/adding-certificate-policies-extension-in-CSR-tp46467p46469.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Precedence of URL between configured one and provided in AIA filed.

[Erwann Abalea]

That's software dependant.
Either one is a valid responder, and either response has the same value, 
there's no priority.


--
Erwann ABALEA

Le 02/09/2013 10:27, deepak.kathuria a écrit :

Hi,

I am using openssl OCSP utility as OCSP Responder in linux platform. At OCSP
Requester side, if OCSP Responder URL is coniguered and OCSP Responder URL
is also present in subject certificate (AIA field of extension), then which
one will get precedence- configued one or provided by AIA extension of the
subjcet certificate?



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] X509 CRLs

[Erwann Abalea]

Bonjour,

Le 27/08/2013 18:14, Thaddeus Fuller a écrit :

Hello all,

I had a couple questions about X509 CRLs.

1) It appears that OpenSSL does not check my tree against the CRLs I provide. 
If I revoke my own leaf certificate, and establish mutually-authenticated SSL, 
OpenSSL does not prevent the connection from going through. However if I revoke 
the peer's leaf certificate, it will fail with the revoked certificate error. 
Is this by intention? Should I manually check my tree against the CRL before 
allowing the user to establish a connection?


If A needs to authenticate itself to B, then A presents its own 
certificate, and B must validate A's certificate: correct chaining and 
revocation status.
A doesn't need to check that its own certificate isn't revoked before 
trying to send it to B, that's B's duty.



2) Can a child CA revoke a parent CA? If I import a CRL to my system, should I check only 
the children of the CA for a matching serial and mark that certificate 
Revoked, or should I also check the parents for revocation? What about a 
certificate that is signed by a parent, but isn't in the child's chain?


A child CA cannot revoke a parent CA, of course. The revocation status 
check should be done for each certificate in the chain (except the root, 
for not so obvious reasons).



Two example PKI trees:
A - B - C - D
A - E - F - G

Let's say that certificate authority B imports a CRL. Which certificates 
should be checked for revocation?


If you want to verify certificate D, then you must verify its revocation 
status regarding to a CRL produced by C. And then you must verify C's 
revocation status according to the CRL produced by B. And finally you 
must verify B's revocation status according to the CRL produced by A.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] RE: CA hierarchy / pathlen:0

[Erwann Abalea]

Bonjour,

Le 22/08/2013 14:56, Peter1234 a écrit :

You misunderstand how it’s supposed to work.
OpenSSL does not prevent you from signing anything.  It can’t; for example,
you could use other software and generate the signature.

Instead, when the recipient gets a certificate, and verifies the chain, it
should reject the chain because the signing CA was not legitimate (pathlen
exceeded).



Hi Rich,

following lines are copied from RFC 5280:

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.

I assumed openssl would conform to RFC standards and therfore supposed that
it takes care of pathlengths specified in CA certificates.


This applies to relying parties, i.e. the entity that performs the 
certificate validation.
As Rich wrote, anybody having the private key could sign anything (even 
without OpenSSL), and it's the relying party duty to verify that the 
certificate chain matches constraints. In that role, OpenSSL correctly 
checks those constraints.


Take your CA3 example, sign another certificate below it, and ask 
OpenSSL to verify the chain.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: Displaying cert with ecdsa

[Erwann Abalea]

Le 16/08/2013 20:10, Robert Moskowitz a écrit :


On 08/14/2013 05:37 PM, Dave Thompson wrote:

From: owner-openssl-us...@openssl.org On Behalf Of Robert Moskowitz
Sent: Wednesday, 14 August, 2013 15:49
I have a CA cert in pem format that uses ecdsa.  I have tried
to display the contents with:

openssl x509 -in x509-ca.pem -text -nameopt multiline -noout

I get errors:

  Subject Public Key Info:
  Public Key Algorithm: id-ecPublicKey
  Unable to load Public Key
140661212006240:error:0609E09C:digital envelope
routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239:
140661212006240:error:0B07706F:x509 certificate
routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155:

Is there an option I need to add?  Is there something special
with this cert's Public Key Algorithm?

I'm pretty sure not. OpenSSL versions before 1.0.0 needed a
cipherstring option to use ECC suites *in SSL/TLS protocol*,
but local operations have worked as long as I remember.

What version of OpenSSL are you running, and how was it built?
In particular was it from official source, or patched?


I am running Fedora 16, standard biuld stuff. Yes, I know it is time 
to upgrade...


Fedora, an ECC certificate. This can't work, for legal reasons. Blame 
RedHat.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Country Name field in CA generated by openssl is encoded as PRINTABLESTRING

[Erwann Abalea]

countryName is ALWAYS a PrintableString, and is ALWAYS 2 characters long.
See X.520 for a normative definition, included in RFC5280 for information.

--
Erwann ABALEA

Le 20/06/2013 18:33, phildoch a écrit :

Country Name field in CA generated by openssl is encoded as PRINTABLESTRING
while other fields are UTF8STRING

I am generating a CA certificate with openssl version 1.0.1e with the
following commands:

openssl ecparam -out ec_key.pem -name secp384r1 -genkey
openssl req -new -key ec_key.pem -x509 -nodes -days 1460 -out ec_ca_cert.pem

At the end of this process I enter DN fields as follow:
Country Name (2 letter code) [AU]:US
State or Province Name (Full Name) [Some-State]:Florida
Locality Name (eg, city)[]:Miami
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Coca Cola
Organization Unit Name (eg, section) []:Drinks
Common Name (e.g. server FQDN or YOUR name) []:Miki
Email Address []:

I convert the ec_ca_cert.pem certificate to DER format:
openssl x509 -in ec_ca_cert.pem -inform PEM -out ec_ca_cert.der -outform DER

When I edit the ec_ca_cert.der file with an HEX editor, I can clearly see
that the Country field is encoded as PRINTABLESTRING (Type=0x13) while all
the other fields (Locality Name, Organization Name, Organization Unit Name,
Common Name) are encoded as UTF8STRING (Type=0x0c).

Is there a reason for this, or is there something wrong with my process, or
an openssl issue?

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Certificate chain issue

[Erwann Abalea]

Try these:
 - split the certificates from your CA/cecert.pem into individual files 
with correct hashes
 - run strace -eopen openssl verify -CApath yourcacertsdirectory 
client.cert


--
Erwann ABALEA

Le 04/06/2013 09:02, Leon Brits a écrit :


Hi all,

I have just created a new CA which has the extension to allow client 
authentication. My previous CA worked fine without this extension but 
some client application now requires that I set it. So I've created a 
new client key pair and signed it with the new CA, but when I use 
openssl verify to test them, they do not verify.


I get the following error:

$ openssl verify -CAfile CA/cacert.pem client.cert

stdin: CN = 
d8ab98a0252208818a29d5548bd833d40e85e4fa14bf146dc04be5139418fae2, 
emailAddress = a...@gmail.com mailto:ljbr...@gmail.com, C = aa


error 20 at 0 depth lookup:unable to get local issuer certificate

If I look at the new client certificate's chain I get:

~$ openssl x509 -issuer -subject -noout -in client.cert

issuer= 
/C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost


subject= 
/CN=d8ab98a0252208818a29d5548bd833d40e85e4fa14bf146dc04be5139418fae2/emailAddress=a...@gmail.com 
mailto:ljbr...@gmail.com/C=aa


and the CA certificate is selfsigned:

~$ openssl x509 -issuer -subject -noout -in CA/cacert.pem

issuer= 
/C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost


subject= 
/C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost


The extensions for the CA are now:

X509v3 extensions:

X509v3 Subject Key Identifier:

ED:51:C6:3B:A3:72:B3:F5:33:80:F0:7C:15:FD:CE:FF:6C:B6:07:6A

X509v3 Authority Key Identifier:

keyid:ED:51:C6:3B:A3:72:B3:F5:33:80:F0:7C:15:FD:CE:FF:6C:B6:07:6A

DirName:/C=aa/ST=gg/L=ppp/O=mod/OU=eng/CN=crypto-admin/emailAddress=root@localhost

serial:A4:48:38:09:CB:16:6A:D0

X509v3 Basic Constraints:

CA:TRUE

X509v3 Key Usage:

Certificate Sign, CRL Sign

I just cannot understand this verification problem - the client is 
directly signed by the root CA!?


Any help appreciated

Thanks

LJB

Re: [openssl-users] Display CSR w/ subjectAltName

[Erwann Abalea]

Are you sure there's a SAN extension in the displayed CSR?
Dump the entire content with asn1parse.

--
Erwann ABALEA

Le 23/05/2013 17:41, Craig White a écrit :

I want to be able to view CSR's with subjectAltName's but I can't figure out 
any way to make it happen. I have poured over the man pages and googled it to 
death already.

Ubuntu OpenSSL 0.9.8k-7ubuntu8.14 if that matters

openssl req -noout -text -in SOME_FILE.csr

gives me the contents of the CSR but not the subjectAltNames embedded in the 
CSR.

Added -nameopt multiline which is cool but still no ultimate joy

Can someone throw me a bone here?



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] How to create CSR with SN attribute

[Erwann Abalea]

That question has been answered a few days ago. Here's an example:

openssl req -new -newkey rsa:2048 -keyout dumb.key -nodes -out dumb.req 
-subj /C=UT/O=Whatever/GN=Per/SN=Edlund


--
Erwann ABALEA

Le 20/05/2013 16:47, Per Edlund a écrit :

Hello!

I need to create a key and a csr with SN=x but can't find any way to do 
this.

Does anyone know how to do this?

Kind regards
/Per Edlund


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] openssl req -x509 Serial Number

[Erwann Abalea]

Le 28/04/2013 20:26, redpath a écrit :

When an x509 is created using the openssl command it creates a default serial
number if one not supplied
How is this serial number created (algorithm) in general.


A 64bits random number.


openssl req -x509  etcetera

The default serial number is quite long so just using time_t (long) to set
the serial number is not very long (four bytes). So I am interested in what
it does.


You could also read apps/req.c source code.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] RE: extended x509 custom, Attributes and BEGIN Certificate size

[Erwann ABALEA]

The certificate is only contained between the BEGIN/END markers
(including them). The text shown before is a text representation of
the certificate, for your eyes only, and can be discarded (it's not
used, by no software, never).

Hodie V Kal. Mai. MMXIII, redpath scripsit:
 Okay but it seems duplicate in information. The extended attributes have
 information and the PEM has the base64 encoding below. Is there a way not to
 have this duplicate info for efficient size?

-- 
Erwann ABALEA erwann.aba...@keynectis.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] X509 custom extension

[Erwann Abalea]

Bonjour,

Le 26/04/2013 15:15, redpath a écrit :

I am adding a custom extension to an x509 a png icon basically (bytes).
Since the png icon is too large to post the data I have subsituted it with
a
file called sample.txt that has a text line This is a sample.
The code excerpt to add the extension is below.


   getdata(sample.txt,length);  //abstracted

   nid = OBJ_create(1.03, samplealias, sample);


Avoid the use of existing OIDs for private purpose. 1.3 is already 
defined (/ISO/Identified-Organization).
Register for your own private OID (ask for one under the 1.3.6.1.4.1 
branch, for example), and do whatever you want in your sandbox.



   ASN1_OCTET_STRING_set(os,(unsigned char*)data,length);
   ret = X509_EXTENSION_create_by_NID( NULL, nid, 0, os );
  X509_add_ext(x,ret,-1);

*I have 2 Questions
(1) the x509 before adding a custom extension looks like this*

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 0 (0x0)
 Signature Algorithm: sha1WithRSAEncryption
 Issuer: C=UK, CN=OpenSSL Group
 Validity
 Not Before: Apr 26 12:48:18 2013 GMT
 Not After : Apr 26 12:48:18 2014 GMT
 Subject: C=UK, CN=OpenSSL Group
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public Key: (512 bit)
 Modulus (512 bit):
 00:df:82:85:c6:0b:18:50:75:35:6b:3b:cc:2e:94:
 a0:b4:a6:8e:21:19:9e:28:ca:46:54:b5:5f:75:c4:
 bb:a2:19:c7:51:c4:19:0d:ef:ce:65:39:0f:90:90:
 2b:2a:46:76:f4:03:be:a7:f2:76:4d:26:af:8e:ce:
 84:43:52:74:d1
 Exponent: 65537 (0x10001)
 Signature Algorithm: sha1WithRSAEncryption
 8b:a6:4d:0a:0b:b6:8f:13:f6:58:10:a2:a4:cc:9c:ba:37:8c:
 53:07:22:f0:93:29:17:78:b4:0a:28:91:ae:24:86:bf:2f:bf:
 d8:bc:4a:97:bd:36:09:c2:b3:21:fa:fe:fe:90:91:31:00:5e:
 01:f9:19:1b:54:89:f9:1f:b5:fa
-BEGIN CERTIFICATE-
MIIBODCB46ADAgECAgEAMA0GCSqGSIb3DQEBBQUAMCUxCzAJBgNVBAYTAlVLMRYw
FAYDVQQDEw1PcGVuU1NMIEdyb3VwMB4XDTEzMDQyNjEyNDgxOFoXDTE0MDQyNjEy
NDgxOFowJTELMAkGA1UEBhMCVUsxFjAUBgNVBAMTDU9wZW5TU0wgR3JvdXAwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEA34KFxgsYUHU1azvMLpSgtKaOIRmeKMpGVLVf
dcS7ohnHUcQZDe/OZTkPkJArKkZ29AO+p/J2TSavjs6EQ1J00QIDAQABMA0GCSqG
SIb3DQEBBQUAA0EAi6ZNCgu2jxP2WBCipMycujeMUwci8JMpF3i0CiiRriSGvy+/
2LxKl702CcKzIfr+/pCRMQBeAfkZG1SJ+R+1+g==
-END CERTIFICATE-


*After I added the extension you can see my field added and thats great*

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 0 (0x0)
 Signature Algorithm: sha1WithRSAEncryption
 Issuer: C=UK, CN=OpenSSL Group
 Validity
 Not Before: Apr 26 12:49:39 2013 GMT
 Not After : Apr 26 12:49:39 2014 GMT
 Subject: C=UK, CN=OpenSSL Group
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public Key: (512 bit)
 Modulus (512 bit):
 00:cf:53:10:b6:c4:ef:f3:a7:7d:39:64:18:75:2a:
 77:a9:82:52:59:a9:29:e8:d6:57:de:9e:4e:3f:6a:
 69:b6:b5:48:c2:ab:5a:1e:f0:c4:8d:25:2a:3d:21:
 04:49:59:46:b6:d5:23:39:38:26:68:71:1d:67:31:
 d4:dc:a4:3b:09
 Exponent: 65537 (0x10001)
*X509v3 extensions:
 sample:
 This is a sample
*

 Signature Algorithm: sha1WithRSAEncryption
 af:5e:52:9d:cc:e7:5e:2c:63:81:76:53:c6:92:cb:81:3d:a7:
 16:63:3d:97:2a:c1:dc:12:64:e1:5b:16:f3:8b:f4:5e:e2:0c:
 3f:04:4d:b8:67:b7:35:75:8a:7b:b0:3a:c8:f0:7b:7d:2e:b3:
 b3:6a:9d:07:21:87:32:b6:4d:4f
-BEGIN CERTIFICATE-
MIIBVjCCAQCgAwIBAgIBADANBgkqhkiG9w0BAQUFADAlMQswCQYDVQQGEwJVSzEW
MBQGA1UEAxMNT3BlblNTTCBHcm91cDAeFw0xMzA0MjYxMjQ5MzlaFw0xNDA0MjYx
MjQ5MzlaMCUxCzAJBgNVBAYTAlVLMRYwFAYDVQQDEw1PcGVuU1NMIEdyb3VwMFww
DQYJKoZIhvcNAQEBBQADSwAwSAJBAM9TELbE7/OnfTlkGHUqd6mCUlmpKejWV96e
Tj9qaba1SMKrWh7wxI0lKj0hBElZRrbVIzk4JmhxHWcx1NykOwkCAwEAAaMbMBkw
FwYBKwQSVGhpcyBpcyBhIHNhbXBsZQoKMA0GCSqGSIb3DQEBBQUAA0EAr15Snczn
XixjgXZTxpLLgT2nFmM9lyrB3BJk4VsW84v0XuIMPwRNuGe3NXWKe7A6yPB7fS6z
s2qdByGHMrZNTw==
-END CERTIFICATE-


The extension is here, it looks fine, but it's not.
The content of your extension is a simple string: This is a 
sample\n\n, where the content of an extension is supposed to be the DER 
encoding of something.



*But I noticed that the end data has gotten larger?

-BEGIN CERTIFICATE-
-END CERTIFICATE-*

*And of course it is much larger when using a real  PNG, very much so.. Why
is that?


I'm not sure I understand the question. You had no extension in your 
first certificate, you added an extension with 18 bytes of content, and 
are wondering if it's normal that your certificate is now bigger?
To the 18 bytes of content, you have to add 2 bytes 

Re: [openssl-users] handling of expired certificates

[Erwann Abalea]

OpenSSL doesn't take care of the expiration of your certificate 
automagically in the background and call some function in your 
application to asynchronously tell that the certificate you received 
several seconds ago has now expired.
Identically, OpenSSL doesn't take care of external events that may now 
declare your certificate as revoked.


Verify the validity of the certificate at the current time. If you want 
to periodically check for the validity of the certificate because you're 
using it for a looong session, that's up to you.


--
Erwann ABALEA

Le 23/04/2013 19:17, Vijaya Venkatachalam a écrit :

Hi
I am new to openssl application development.
I had a question on how to handle expired certificates.
So at the time of openssl connection establishment, the certificate is 
valid.

But while the connection is still up, the certificate expires.
Is the application supposed to handle this or does openssl handle this?
what should be the application behavior on certificate expiry?
Thanks,
Vijaya

Re: [openssl-dev] MD5 in openSSL internals

[Erwann Abalea]

MD5 is used in TLS1.0 for RSA signing and random derivation (PRF). See 
RFC2246.

(Please note that OpenSSL hasn't been mentioned in this sentence).

SHA256 used for the PRF is available with TLS1.2 only. SHA256 used for 
the HMAC is available for some ciphersuites defined for TLS1.2 only (but 
I think you could define your own with TLS1.0).


--
Erwann ABALEA

Le 23/04/2013 08:29, Venkataragavan Narayanaswamy a écrit :


Hi,

We are currently analyzing and understanding the security strength of 
the openSSL internal implementation to certify the products.


In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer 
the following or provide me with the documentation reference


1.Does openSSL library use MD5 internally for any operation?

2.Can we have SHA256 in the ciphersuite with TLSv1.0?

Thanks,

Venkat

Re: [openssl-users] Re: [openssl-dev] MD5 in openSSL internals

[Erwann Abalea]

You're right.

PRF in TLS1.0 is done by splitting the secret in 2 parts, hashing the 
first with MD5, hashing the second with SHA1, and XORing the 2 results.
RSA signing in TLS1.0 is done by hashing the data with MD5 and SHA1, 
concatenating the 2 hash results, and signing the 36 bytes result (with 
PKCS#1v1.5 padding).


PRF construct depends on pre-image resistance. MD5 and SHA1 are still 
considered pre-image resistant.
RSA signing depends on collision resistance. MD5 is not collision 
resistant, SHA1 is not considered academically collision resistant, but 
there's no known attack on collision of both MD5 and SHA1 at the same time.


--
Erwann ABALEA

Le 23/04/2013 14:28, David Jacobson a écrit :

Careful about this.  The technically correct answer is misleading.

Yes, MD5 is used in the PRF, but it is XORed with SHA1.  So you get at 
least the strength of stronger of the two.


--David Jacobson

On 4/23/13 3:31 AM, Erwann Abalea wrote:
MD5 is used in TLS1.0 for RSA signing and random derivation (PRF). 
See RFC2246.

(Please note that OpenSSL hasn't been mentioned in this sentence).

SHA256 used for the PRF is available with TLS1.2 only. SHA256 used 
for the HMAC is available for some ciphersuites defined for TLS1.2 
only (but I think you could define your own with TLS1.0).


--
Erwann ABALEA

Le 23/04/2013 08:29, Venkataragavan Narayanaswamy a écrit :


Hi,

We are currently analyzing and understanding the security strength 
of the openSSL internal implementation to certify the products.


In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer 
the following or provide me with the documentation reference


1.Does openSSL library use MD5 internally for any operation?

2.Can we have SHA256 in the ciphersuite with TLSv1.0?

Thanks,

Venkat

Re: [openssl-users] Re: SSL / SMTP

[Erwann Abalea]

Le 17/04/2013 18:40, Joan Moreau a écrit :

Le 17/04/2013 14:18, Viktor Dukhovni a écrit :


On Wed, Apr 17, 2013 at 07:24:23AM +, Joan Moreau wrote:

2013-04-17T09:17:36.573675+02:00 server postfix/smtpd[16725]: 
warning: TLS library problem: 16725:error:140D308A:SSL 
routines:TLS1_SETUP_KEY_BLOCK:cipher or hash 
unavailable:t1_enc.c:597: 2013-04-17T09:17:36.573971+02:00 server 
postfix/smtpd[16725]: lost connection after CONNECT from 
wana-25-254-12-196.wanamaroc.com[196.12.254.25] Can you help ?


No. Install a fresh O/S image on new hardware and use that as your
mail server. If a fresh install with the default Postfix for the
O/S does not work, come back to the Postfix-users list for help.

You've already consumed a lot of cycles on the Postfix-users list.
Now you are trying the openssl-users list without referencing the
prior long thread which shows your system to be messed up.



Please Viktor, I don't need your insults and mis-behaving and lack of 
politeness.


My system is not messed up, I have thousands of people working with 
since ages. Now, i'll appreciate very much some help instead of those 
useless attacks.




Reading the mentioned postfix-users thread, it seems Viktor is right, 
you messed up with your server, compiling and installing your own 
cutting-edge kernels and binaries, without using a package manager, on a 
production server.


You may try to locate the libraries that have been used during 
compilation, and the ones that are used by your running postfix, and 
compare them.
The first answer is to be found somewhere in the compilation logs, the 
answer to the second question can be found running the following:
ps faux | grep postfix | awk '{ print $2 }' | xargs -L 1 lsof -p | grep 
-E libcrypto|libssl
considering that your postfix binary runs under the identity postfix, 
and that you're root (or add a sudo before xargs).


I don't think It's a SHA2 error, as I'm rejected by your server when I 
contact it with RC4-SHA (something that is permitted by your ciphersuite 
string).

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] how to STORE encrypted string in database

[Erwann Abalea]

Your string is not portable (it isn't even a string). Whence, storing 
it as a string in your database isn't a good thing to do.
Try encoding it in base64 after your encryption, and store the result 
(which will be a clean portable string).

An alternative solution is to store your encrypted value as binary data.

In fact, following your link, those are the first 2 answers...

--
Erwann ABALEA

Le 28/03/2013 19:08, Jevin Sonut a écrit :

hi,

i have encrypted a string using Blowfish from Openssl library

i got the following string A▓☼LÝ$øä²↓j╗ú¤Ä:ðï▲

i inserted the data into my database BUT when i retrieved the data i 
got A¦¤LÝ$øä²?j+ú¤Ä:ðï?  (NOT same to the original the one i inserted)


thus when i decrypt the loaded string from the database i donot get 
the original string


Can anyone ply help to solve the problem

i'm using SQLITE and c/c++

I google the problem but came along a c# solution 
http://stackoverflow.com/questions/8389412/md5-encrypted-string-returns-different-from-database-than-it-is-inserted


Can anyone PLZ help

From:-
Shanil J.S

Re: [openssl-users] using multiple keys

[Erwann Abalea]

openssl enc encrypts one file at a time, and can read the first line 
of a file to get the passphrase (in order to derive key and iv).
If you want to provide your own key and iv, you have to do it as command 
line arguments.

Key management is out of scope.

--
Erwann ABALEA

Le 15/03/2013 06:33, Ewen Chan a écrit :

If I have a directory and it has 10 files and I have 10 separate keys
such that key1 is for file1 and key2 is for file2 (etc.); is there a
way to automate the encryption process like that?

Or do I have to run each of the commands separate and instead of
having 10 separate keys in a single keyfile in a list format; that I
would need to split them out into individual keyfiles (e.g. keyfile1,
keyfile2, etc.) and then run the encryption individually (rather than
launching a single encryption job that will process all 10 files with
all 10 keys listed in one keyfile)?

(I hope that this makes sense and that people are kinda getting what
I'm asking here.)

Thanks.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: having a lot of troubles trying to get AES-NI working

[Erwann Abalea]

On a PC under Linux, you can do a cat /proc/cpuinfo and look for aes 
in the flags.

On a PC under any OS, get the CPUID, and look for bit 25 of ECX.
That's not OpenSSL-related.


The use of OPENSSL_ia32cap environment variable allows you to alter the 
CPUID result (only inside OpenSSL), and alter its behaviour. It's not 
resistant to a reboot, it's only process dependant.


Compare the following results:

 * OPENSSL_ia32cap=~0x202 openssl speed -elapsed -evp
   aes-128-cbc
 * openssl speed -elapsed -evp aes-128-cbc


--
Erwann ABALEA

Le 15/03/2013 04:46, Ewen Chan a écrit :

Does it matter whether it's ia32 or ia64 even for an x64 processor?

Shouldn't there be some way for me to check whether AES is enabled or
being used (other than running a speed test) either in dmesg or /proc/
or with openssl itself? I'm a little confused, and surprised/shocked
that there isn't a way to probe the status of whether the AES-NI is a)
present and b) enabled/utilized.

re: OPENSSL_ia32cap=~0x202
so forgive me for asking lots of dumb questions but that would be
$ set OPENSSL_ia32cap=~0x202
$ export OPENSSL_ia32cap

correct?

And how do I re-enable it without having to reboot the system? What's
the value that I should be putting in on the right-hand-side of the
equal sign?

Your help is much appreciated.

Sincerely,
Ewen

On Thu, Mar 14, 2013 at 7:35 PM, Dr. Stephen Henson st...@openssl.org wrote:

On Thu, Mar 14, 2013, Ewen Chan wrote:


So this is a partial continuation from the discussion thread that I
started yesterday in regards to using AES-CBC.

I've got an Intel Core i7 3930K that supports AES-NI and I spent the
greater part of last night trying to get openssl to work or at least
recognize it, but it doesn't seem to want to do that.


It it probably recognising it and you don't realise it. OpenSSL 1.0.1
automatically switches to AES-NI at the EVP level without going through an
explicit AES-NI ENGINE.

You can disable AES-NI detection with the environment variable:

OPENSSL_ia32cap=~0x202

You should see a considerable speed up with openssl speed by comparing the
two.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] using multiple keys

[Erwann Abalea]

Le 15/03/2013 13:54, Ewen Chan a écrit :

Sorry, my bad. Wrong terminology.

(The AES wiki says that it uses a key.) But I was really thinking
about multiple passphrases.


And from this passphrase, a key and IV can be generated. It's more easy 
to remember a passphrase than a bunch of hex digits.



Sorry for the mix up.

So let's say I have three files:
file1
file2
file3

And then I have a passphrase file that contains the following:

Alice
Bob
Charlie

and I want to encrypt file1 with the passphrase Alice; file2 with
the passphrase Bob and file3 with the passphrase Charlie.

Is there a way to get openssl to automatically do that or do I need to
write a program/shell script so that I will automatically increment
one and pull the passphrase from the appropriate passphrase file?


The openssl command-line tool doesn't do that. It can work with one 
passphrase file per file, or you can provide the passphrase as an argument.
If you want to centralize your passphrases, you'll have to write some 
kind of wrapper to extract the good passphrase and provide it to 
openssl enc (either in a dedicated file, or as an argument).



(Disclaimer: I am NOT a programmer. At all. By ANY stretch of the imagination.)


Nobody's perfect :D
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Validation error on generated csr

[Erwann Abalea]

Bonjour,

Le 15/03/2013 14:07, Tim Tassonis a écrit :

Hi

I am trying to generate a csr in a c program by having the signing 
part done by pkcs11 calls, and while I get no errors, the resulting 
csr fails upon validation:


$ openssl req -verify -in wltx.csr
verify failure
2948:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too 
long:.\cry

pto\asn1\asn1_lib.c:150:
2948:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object 
header:.\c

rypto\asn1\tasn_dec.c:1306:
2948:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested 
asn1 error:.\

crypto\asn1\tasn_dec.c:381:Type=X509_SIG
2948:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP 
lib:.\crypto\asn

1\a_verify.c:215:
-BEGIN CERTIFICATE REQUEST-
MIICvjCCAagCAQAwezELMAkGA1UEBhMCQ0gxEzARBgNVBAcTClJhcHBlcnN3aWwx

[...]

BBXO9brFuXld13VuE2xg+VnJ8vo3L7/SCC5ufEJaeSUOvQ==
-END CERTIFICATE REQUEST-



What is RSA signed is the direct SHA1 of the request, without the X509 
encapsulation.


Below is the function that generates the csr, it always succeds, but 
as mentioned, the csr is still invalid


char *gen_csr(char *key_name, struct s_ekva **key_attrs)
{
[...]
inl=ASN1_item_i2d((void 
*)req-req_info,buf_in,ASN1_ITEM_rptr(X509_REQ_INFO));

p = buf_in;
outl=EVP_PKEY_size(pkey);
buf_out = malloc(outl);

sign_mechanism.mechanism = CKM_SHA1_RSA_PKCS;
sign_mechanism.pParameter = NULL;
sign_mechanism.ulParameterLen = 0;

rv = p11-C_SignInit(session, sign_mechanism, prvkey);
if (rv != CKR_OK) {
return NULL;
}
rv = p11-C_Sign(session, p,inl, buf_out, outl);
if (rv != CKR_OK) {
return NULL;
}


You're feeding the PKCS#11 library with the request (the part to be 
signed), while specifying a CKM_SHA1_RSA_PKCS mechanism. The library 
doesn't know it's signing a CSR, and will SHA1 hash the data and RSA 
sign it.


What you have to do it hash your data, prepare an X509_SIG object, set 
its algor to SHA1 (with NULL parameters), and fill the digest part 
with your hash result. Then transform it into DER, and sign it with 
CKM_RSA_PKCS mechanism.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Offline Root CA and CRL generation

[Erwann Abalea]

X.509 allows for a self-signed certificate dedicated to CRL signing 
(with the same name, of course). But that's not acceptable for RFC5280.


You can generate a self-issued certificate dedicated to CRL signing 
(same name, different key, signed by your root). That's acceptable for 
RFC5280, but you'll have to check with your clients. And find a way to 
distribute this certificate.


--
Erwann ABALEA

Le 15/03/2013 15:53, Sven Dreyer a écrit :

Hi List,

I would like to setup an OpenSSL-based offline Root CA.

Certificates issued by this Root CA contain a CDP.

I would like to issue CRLs every 3 days, which would mean that I would 
have to take the offline Root CA online each 3 days.


Is there a way to let the Root CA issue a CRL signer certificate, 
which can then run on a different machine for CRL signature?


For OCSP it seems to be possbile (RFC2560, 2.6 - OCSP Signature 
Authority Delegation). Does anybody know whether it's possible for 
CRL's using OpenSSL?


Thanks for any advice,
Sven
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Offline Root CA and CRL generation

[Erwann Abalea]

Le 15/03/2013 17:01, Sven Dreyer a écrit :

Hi Erwann,

Am 15.03.2013 16:16, schrieb Erwann Abalea:

You can generate a self-issued certificate dedicated to CRL signing
(same name, different key, signed by your root). That's acceptable
for RFC5280, but you'll have to check with your clients. And find a
way to distribute this certificate.


I'm not sure whether I got it right.

My Root CA is named Foobar Root CA with keypair (A).

I would then let Foobar Root CA issue a certificate for Foobar Root 
CA with keypair (B) and attribute keyUsage = cRLSign.


I would then use the certificate for keypair (B) to sign the CRL.

Then, I would distribute the certificates for Foobar Root CA (A) and 
Foobar Root CA (B) to my clients' trusted CA stores.


Is this the way you pointed me to?


Yes. That's one possible solution (possible from a PKI point of view).

Another solution would be to play with indirect CRLs. That involves 
issuing a certificate (with a different name, for example Foobar CRL 
Signer) dedicated to CRL signing, specifying its name in the 
CRLDistributionPoints of your issued certificates, and sign the CRL with 
this certificate+private key (Foobar CRL Signer). That CRL must have a 
critical IssuingDistributionPoint extension with the indirectCRL set to 
true, and at least the first revocation entry must have an extension 
indicating its issuer name (Foobar Root CA). Foobar CRL Signer may be 
issued under a completely different trust chain.
I don't know how well this second solution is supported by clients, and 
I suppose that the Foobar CRL Signer certificate should itself have a 
CRLDP extension pointing to a valid CRL, etc.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] specifying the number of rounds that I would like to use with AES-192-CBC

[Erwann Abalea]

If you change the number of rounds, then it's not AES anymore, but a 
custom Rijndael.
Reading the source code, it appears there's no support for that in 
OpenSSL (and poking inside an AES_KEY to change the number of rounds 
probably won't work).


--
Erwann ABALEA

Le 13/03/2013 14:32, Ewen Chan a écrit :

There's a file that I want to encrypt using AES-192-CBC but with 19
rounds rather than the default 12-rounds.

Is there a way for me to specify the number of rounds that I would
like to use with the AES-192-CBC? (and override the algorithm
defaults)?

Is that something that I can within the openssl command itself (to
encrypt a file) or is the process much more involved than that? And
requires programming/scripting?


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org