Re: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.
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.
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.
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, &siglen, > 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.
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
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
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
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?
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
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. >
Re: [openssl-users] RSA Public Key error
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 Ope
Re: [openssl-users] RSA Public Key error
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
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 >>> -- >>&g
Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates
> Le 13 sept. 2017 à 17:08, Michael Wojcik a > écrit : > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of Michael Richardson >> Sent: Wednesday, September 13, 2017 09:32 >> >> I suspect that the value: literal value 1231235959Z will simply come to >> mean "the end of time", even after the year 10,000. It has a well known >> DER encoding, and one can memcmp() it. > > Personally, I'm really hoping we're not still using ASN.1 in the year 1. Why not? ;) X.680 relies in ISO8601 for the date/time definitions. GeneralizedTime uses the Basic format from ISO8601 for the date (year on 4 digits, month on 2 starting with 01, day on 2 starting with 01), liberal time of day (minutes and/or seconds can be omitted, optional fraction of second/minute/hour depending on what is included), and a timezone from -15h to +15h with a one hour or one minute accuracy, or Z for UTC. BER accepts pretty much everything from this definition, DER has a few restrictions: - in ISO8601, there are 2 different midnights (00:00:00 and 24:00:00), the DER encoding requires such date/time to be transformed into 00:00:00 the day after - DER only accepts the « Z » timezone and not the +/-HH(MM) variant - DER requires the minutes and seconds to be present in the time of day, and no fraction of a second In theory, the very last date/time expressed in ASN.1 is 123124+1500, and it would be valid if expressed in BER. In DER, the very last date/time would have been 1231235960Z (in case a positive leap second gets inserted that day), but something else was preferred. It’s still possible that there’s a negative leap second happening at that exact day, removing second 59 completely. Just think of this as a magical value. Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
My proposal. Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a block cipher operating on blocks of k bits, and operate this block cipher in CTR mode, with a proper secret key and secret starting counter. That way, no collision detection is necessary, you’ll be able to generate 2^(k/2) unique k bits longs serial numbers (in fact, you can generate 2^k unique serial numbers, but after 2^(k/2) you lose some security guarantees). With 3DES, k=64, and with AES, k=128. Since you need to make a tradeoff between security and size, you can play with lightweight block ciphers such as Simon, Speck, or find some tweakable lightweight block cipher, maybe from the ECRYPT portfolio (it’s down at this moment). Again, the 64bits coming from a CSPRNG is for public CAs only, and the uniqueness of a serial number is a dirty hack to be able to use a non collision-resistant hash function a little longer. If you’re confident the hash function used for signature is collision resistant (for example a member of the SHA2 or SHA3 family), and you have a purely private CA, don’t bother will all this, the only hard requirement is the unicity of the tuple {CA name, serial number}. Cordialement, Erwann Abalea > Le 21 août 2017 à 15:44, Robert Moskowitz a écrit : > > > > On 08/21/2017 09:36 AM, Salz, Rich wrote: >> ➢ Thus how large does this random number have >> >> It’s also to protect against predicting serial numbers and being able to >> leverage that. It’s not just (nor really mainly) the MD5 digest attacks. >> According to CABForum, you need 8 octets. No reason not to use more if you >> can. > > Sure there is. On constrained systems with constrained communication links. > Every byte counts. My real thrust on this is for IoT. To get IoT developers > to build around certs and know their products work with them instead of, well > we will get to it eventually. > > When I work with 802.15.4 communications with a 128 byte MTU, there is > considerable debate over every byte sent. When you tell an IoT chip maker > that they have to go from 32KB memory to 100MB, they walk out of the room. > > Oh, I want DOTS and I2NSF developers to be working with certs from the get > go, instead waiting for deployments and getting 'production' certs and THEN > discovering what works and what does not. But IoT is in many ways more of a > challenge. > > So yes, size matters. > >> >> >> ➢ page was talking about in conjunction with the -CA option. With 'openssl >> ca' use of the serial file is mandatory according to the man page. >> There are no command line options for it. >> >> Fixed in master and will be part of the next releases; the –rand_serial flag. >> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] More on cert serialnumbers
> Le 18 août 2017 à 15:18, Mark H. Wood a écrit : > > On Thu, Aug 17, 2017 at 03:29:56PM +0000, 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
> Le 17 août 2017 à 17:36, Jeffrey Walton a écrit : > > On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea > wrote: >> >>> Le 17 août 2017 à 17:26, Jeffrey Walton a écrit : >>> >>>>> When you see a name like "example.com" in the CN, its usually a CA >>>>> including a domain name and not a hostname. >>>> >>>> That's nonsense. >>> >>> If a certificate is issued under CA/B policies, and CN=example.com but >>> it _lacks_ SAN=example.com, then its a not a hostname and it should >>> not be matched. >> >> Such a certificate would be mis-issued and be revoked immediately. CN MUST >> be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the >> value in CN MUST be present in the SAN extension. > > Oh, you would have some fun watching how various user agents handle > that scenario. For your first stop, check out how OpenSSL handles it. I’m sure some user agents can have strange behaviors on such certificates. My remark took into consideration the CA/B policies. If such a certificate falls down under the CA/B policies (issued by a public CA, and a TLS server certificate), then it’s invalid. Some browsers (maybe all?) ignore the CN if the SAN extension is present, even for private CAs. Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Implementing deprecation of commonname and emailaddress
> Le 17 août 2017 à 17:26, Jeffrey Walton a écrit : > >>> When you see a name like "example.com" in the CN, its usually a CA >>> including a domain name and not a hostname. >> >> That's nonsense. > > If a certificate is issued under CA/B policies, and CN=example.com but > it _lacks_ SAN=example.com, then its a not a hostname and it should > not be matched. Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension. Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] More on cert serialnumbers
Bonjour, > Le 17 août 2017 à 17:10, Robert Moskowitz a écrit : > > > > On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote: >> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes. >> Which means, you want to make sure the high bit is off, else the DER >> encoding will make it 21 bytes. >> >> So the new –rand_serial flag I am adding to the CA command will make call >> RAND_bytes to get 18 bytes. >> >> >> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" >> wrote: >> >> https://cabforum.org/2016/07/08/ballot-164/ > > “Effective September 30, 2016, CAs SHALL generate Certificate serial numbers > greater than zero (0) containing at least 64 bits of output from a CSPRNG.” > > What does "64 bits of output from a CSPRNG" mean here? A 4 octet serial > number is OK? Or 2^64 bit serial number represented in HEX (how long is > that?) That means that the serial number SHALL be at least 64 bits (8 octets) long, and at least 64 of the bits of the serial number come from a cryptographically strong pseudo random number generator. The BR are for public CAs, not private CAs; even if some of those requirements are considered « good practice » (the 64 bits out of a CSPRNG is such a req), they cannot be forced on private CAs. And unless some or all of the browsers also apply these requirements to private CAs, you’re not forced to follow them all. The 20 octets max comes from RFC5280, keep it. MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant anymore). The 64 bits from a CSPRNG is a tradeoff allowing the use of a non-collision-resistant hash function for slightly longer for transition periods, it’s nice if you can easily follow it, but browsers probably won’t enforce it. The 2048bits minimum RSA key is really a good practice and shouldn’t be left over. Switch to ECDSA if your target permits it. The CN deprecation and use of SAN:dNSName instead is a target of some browsers for private CAs; it may require more work for you, but there’s a benefit. CN has been populated with too much garbage (FQDN, domain, service name, IP address, person name, …), the SAN extension has nice baskets to put your eggs in (dNSName and iPAddress), and it works beautifully with NameConstraints. Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] keyusage digitalSignature in CA certs
Bonjour, > Le 17 août 2017 à 15:20, Robert Moskowitz a écrit : > > Should digitalSignature be included in keyusage in CA certs? It depends on what you plan to do with the corresponding private key. If you want this private key to sign messages other than certificates and CRLs (such as OCSP responses), then yes. > > https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html > > Includes it. > > https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898 > > Does not include it. > > It seems to make a root or intermediate CA be able to have more purposes than > it should? e.g. > > SSL client : Yes > SSL server : Yes > S/MIME signing : Yes This is the result of an analysis of the keyUsage *and* the extendedKeyUsage extensions (and maybe obsolete Netscape proprietary ones). > So which is the right for a CA's key usage? That really depends on what you want it to be valid for. keyUsage=keyCertSign is fine for certificate signing keyUsage=cRLSign is fine for CRL signing keyUsage=digitalSignature is fine for OCSP signing The other bits are not that common for a CA. You can achieve the capabilities with different certificates. For example, a keyCertSign-only CA cert can self-issue a cRLSign certificate in order to produce CRLs and a digitalSignature certificate to sign OCSP responses, or an issuing CA can issue different certificates for the same CA (they all have the same Subject, which is different from the issuing’s Subject) but for different purposes (and thus different keyUsage bits). Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
Bonjour, > Le 16 août 2017 à 16:51, Jakob Bohm a écrit : > > On 16/08/2017 16:32, Tom Browder wrote: >> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users >> mailto:openssl-users@openssl.org>> wrote: >> >>➢ So, in summary, do I need to ensure cert serial numbers are >>unique 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
Bonjour, Add « -sigalgs SHA256+RSA » to one of your command lines. Cordialement, Erwann Abalea Le 9 juin 2017 à 09:45, Ignacio Alamo Corsino 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?
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 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 mailto:openssl-users-boun...@openssl.org>> im Auftrag von Viktor Dukhovni 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 > 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
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 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
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 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
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 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 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
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 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
Bonjour, Le 22 juil. 2016 à 08:44, Gupta, Saurabh mailto:saurabh.gu...@cavium.com>> 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
> 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
> 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
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 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
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 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 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
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 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 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 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
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 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
Bonjour, CCM mode is already implemented in OpenSSL. Cordialement, Erwann Abalea Le 24 mai 2016 à 17:43, Christian Adja mailto:christian_a...@yahoo.it>> a écrit : Il Martedì 24 Maggio 2016 17:21, Christian Adja 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?
Bonjour Stephan, Le 9 févr. 2016 à 12:29, Stephan Mühlstrasser 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 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] Is the structure of this CMS object correct?
Bonjour, Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser mailto:s...@pdflib.com>> 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 5 bytes skipped ]
Re: [openssl-users] OCSP service dependant on time valid CRLs
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 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&node=61627&i=0> Le 10 déc. 2015 à 18:29, socket <[hidden email]<http://user/SendEmail.jtp?type=node&node=61627&i=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 b
Re: [openssl-users] OCSP service dependant on time valid CRLs
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 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
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?
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
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 > 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 > 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 > <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 -in -out >> >> 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] Converting Bin format to X509 format
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 > 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 -in -out > > 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] OCSP: ocsp.omniroot.com/baltimore/... - what is it exactly?
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
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
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?
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 -- 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?
(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
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
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
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
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?
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
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
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
Le 27/03/2014 11:14, Jeffrey Walton a écrit : On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek 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
Le 25/03/2014 23:08, Zack Williams a écrit : On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea 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
Le 25/03/2014 17:44, Zack Williams a écrit : On Fri, Mar 21, 2014 at 12:25 AM, Stefan H. Holek 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
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
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
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
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
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
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
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.
Re: [openssl-users] Re: Bad OIDs
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
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
Bad OIDs (was: Re: Verification of a x509 certificate signature)
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. <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] CA certificate bundle bogus certs
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] Need to send CN attribute in TeletexString/T61String format for ASN1DN Id and certificate
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] OpenSSL doesn't treat RFC 3280 validations as an error?
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] Re: OpenSSL doesn't treat RFC 3280 validations as an error?
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 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?
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=2&t=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] Is aesni-intel module required for openssl
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
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
Bonjour, Le 11/10/2013 03:35, nehakochar a écrit : Rajesh Malepati wrote On Wed, Jul 24, 2013 at 9:30 PM, kirpit < kirpit@ > 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
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
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.
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
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
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
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
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
Try these: - split the certificates from your CA/cecert.pem into individual files with correct hashes - run "strace -eopen openssl verify -CApath 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
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
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
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
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 __ 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
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
Re: [openssl-users] handling of expired certificates
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-users] Re: [openssl-dev] MD5 in openSSL internals
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-dev] MD5 in openSSL internals
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
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
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] Offline Root CA and CRL generation
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] Offline Root CA and CRL generation
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] Validation error on generated csr
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] using multiple keys
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] Re: having a lot of troubles trying to get AES-NI working
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 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
"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] specifying the number of rounds that I would like to use with AES-192-CBC
Le 13/03/2013 20:06, Ewen Chan a écrit : I'm asking about the '-engine aesni' flag because when I google "openssl aes-ni" - that's what comes up. I've never used it before, but I'm about to as I've recently aquired a system that supports AES-NI. I'm also asking because I'm about to encrypt a whole bunch of files and some of them are quite large, so I want to have an idea if the encryption job is going to be something that's going to be done in a few minutes, a few hours, or a few days? Define "quite large". By disabling AES-NI detection on my laptop, I can encrypt files at about 225MB/s (1 GB in 4.5 seconds, AES-128-CBC). That's much faster than what my SATA harddrive can do. Disabling SSE* and MMX instructions allow the same machine to encrypt data at about 82MB/s (1 GB in 13 seconds). Again, more than enough to saturate my hard drive. I was under the impression (based on the documentation and what I've been able to find online on google) that you had to invoke the AES-NI by using the '-engine' flag; but I guess from what you're saying, that that's not true. That's useless for "openssl enc". That may be useful for "openssl speed" (as "-evp" may also be useful), but it's a different goal. And it can also depend on your hardware, your OpenSSL version, and compilation flags. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org