Re: [openssl-users] specifying the number of rounds that I would like to use with AES-192-CBC
The algorithm Rijndael has some knobs you can turn to tune. The standard AES has these parameters fixed in stone. AES-192 is effectively less secure than AES-256 because of the key length and number of rounds. But less secure may be secure enough. In fact, AES-128 is secure enough for most uses. Number of rounds is important for AES security as it is for any other algorithm (think about attacks on reduced-rounds AES/SHA/whatever). -- Erwann ABALEA Le 13/03/2013 15:31, Ewen Chan a écrit : So the algorithms include the number of rounds? I thought that it would only describe the math process and that it would be independent of the number of rounds (so long as you meed Rijndael's minimum - which is what the current number of rounds is set/default as). I did not know that. Hmmmthanks. Does this mean that a AES-192-CBC is less secure than an AES-256-CBC because of the key length and the number of rounds associated with that; or am I understanding that wrong - that the number of rounds has less-so to do with the security of the algorithm compared to the key length? On Wed, Mar 13, 2013 at 10:24 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: If you change the number of rounds, then it's not AES anymore, but a custom Rijndael. Reading the source code, it appears there's no support for that in OpenSSL (and poking inside an AES_KEY to change the number of rounds probably won't work). -- Erwann ABALEA Le 13/03/2013 14:32, Ewen Chan a écrit : There's a file that I want to encrypt using AES-192-CBC but with 19 rounds rather than the default 12-rounds. Is there a way for me to specify the number of rounds that I would like to use with the AES-192-CBC? (and override the algorithm defaults)? Is that something that I can within the openssl command itself (to encrypt a file) or is the process much more involved than that? And requires programming/scripting? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] specifying the number of rounds that I would like to use with AES-192-CBC
GPGPU isn't natively supported. You can write your own engine if you want, but I think memory transfers will dominate the cost. AES-NI is natively supported (I get about 550MB/s on my i5 M540 @2.53 GHz for 8k blocks). -- Erwann ABALEA Le 13/03/2013 16:49, Ewen Chan a écrit : Would it be faster to encrypt/decrypt AES-256-CBC with an AES-NI enabled CPU or would it faster do it with a GPGPU? Does OpenSSL even support GPU acceleration? On Wed, Mar 13, 2013 at 11:44 AM, Ewen Chan chan.e...@gmail.com wrote: Thanks. On Wed, Mar 13, 2013 at 10:56 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: The algorithm Rijndael has some knobs you can turn to tune. The standard AES has these parameters fixed in stone. AES-192 is effectively less secure than AES-256 because of the key length and number of rounds. But less secure may be secure enough. In fact, AES-128 is secure enough for most uses. Number of rounds is important for AES security as it is for any other algorithm (think about attacks on reduced-rounds AES/SHA/whatever). -- Erwann ABALEA Le 13/03/2013 15:31, Ewen Chan a écrit : So the algorithms include the number of rounds? I thought that it would only describe the math process and that it would be independent of the number of rounds (so long as you meed Rijndael's minimum - which is what the current number of rounds is set/default as). I did not know that. Hmmmthanks. Does this mean that a AES-192-CBC is less secure than an AES-256-CBC because of the key length and the number of rounds associated with that; or am I understanding that wrong - that the number of rounds has less-so to do with the security of the algorithm compared to the key length? On Wed, Mar 13, 2013 at 10:24 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: If you change the number of rounds, then it's not AES anymore, but a custom Rijndael. Reading the source code, it appears there's no support for that in OpenSSL (and poking inside an AES_KEY to change the number of rounds probably won't work). -- Erwann ABALEA Le 13/03/2013 14:32, Ewen Chan a écrit : There's a file that I want to encrypt using AES-192-CBC but with 19 rounds rather than the default 12-rounds. Is there a way for me to specify the number of rounds that I would like to use with the AES-192-CBC? (and override the algorithm defaults)? Is that something that I can within the openssl command itself (to encrypt a file) or is the process much more involved than that? And requires programming/scripting? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ 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 17:17, Ewen Chan a écrit : I'm quite new to openSSL and AES and cryptography as a whole, so please forgive my stupid questions. You then may start by reading the different manpages, then. OpenSSL is a large beast, and you won't do anything useful without reading. I've read that because of the way that the AES-CBC works that it depends on the result from the previous round in order to encrypt the current round that it is inherently not well suited for parallelization; which I am then guessing that it is very possible that it would run (a LOT) slower on GPGPU than it would on an AES-NI enabled CPU. Would that be a fair and safe assumption? That's right. You can achieve better performance with CTR mode, for example. But even there, I doubt you can beat AES-NI. I'm also looking online and through the man pages and it seems like that people are invoking the aesni by using the command: openssl -engine aesni -evp aes-256-cbc ... what's the '-evp' flag for? It means use the EVP interface. EVP is a higher level interface to cryptographic primitives. In the case of AES, it can make use of AES-NI instructions if available. That's useful only if you plan to code using the OpenSSL library. On Wed, Mar 13, 2013 at 12:12 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: GPGPU isn't natively supported. You can write your own engine if you want, but I think memory transfers will dominate the cost. AES-NI is natively supported (I get about 550MB/s on my i5 M540 @2.53 GHz for 8k blocks). -- Erwann ABALEA Le 13/03/2013 16:49, Ewen Chan a écrit : Would it be faster to encrypt/decrypt AES-256-CBC with an AES-NI enabled CPU or would it faster do it with a GPGPU? Does OpenSSL even support GPU acceleration? On Wed, Mar 13, 2013 at 11:44 AM, Ewen Chan chan.e...@gmail.com wrote: Thanks. On Wed, Mar 13, 2013 at 10:56 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: The algorithm Rijndael has some knobs you can turn to tune. The standard AES has these parameters fixed in stone. AES-192 is effectively less secure than AES-256 because of the key length and number of rounds. But less secure may be secure enough. In fact, AES-128 is secure enough for most uses. Number of rounds is important for AES security as it is for any other algorithm (think about attacks on reduced-rounds AES/SHA/whatever). -- Erwann ABALEA Le 13/03/2013 15:31, Ewen Chan a écrit : So the algorithms include the number of rounds? I thought that it would only describe the math process and that it would be independent of the number of rounds (so long as you meed Rijndael's minimum - which is what the current number of rounds is set/default as). I did not know that. Hmmmthanks. Does this mean that a AES-192-CBC is less secure than an AES-256-CBC because of the key length and the number of rounds associated with that; or am I understanding that wrong - that the number of rounds has less-so to do with the security of the algorithm compared to the key length? On Wed, Mar 13, 2013 at 10:24 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: If you change the number of rounds, then it's not AES anymore, but a custom Rijndael. Reading the source code, it appears there's no support for that in OpenSSL (and poking inside an AES_KEY to change the number of rounds probably won't work). -- Erwann ABALEA Le 13/03/2013 14:32, Ewen Chan a écrit : There's a file that I want to encrypt using AES-192-CBC but with 19 rounds rather than the default 12-rounds. Is there a way for me to specify the number of rounds that I would like to use with the AES-192-CBC? (and override the algorithm defaults)? Is that something that I can within the openssl command itself (to encrypt a file) or is the process much more involved than that? And requires programming/scripting? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ 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
If what you want is simply encrypt and decrypt files using command-line openssl executable, then you don't need to play with engine or evp options. openssl enc uses the EVP interface, which in turn will make use of AES-NI instructions if available (or SSE3, SSE2, SSE, anything available on the runtime platform to speed it up). -- Erwann ABALEA Le 13/03/2013 18:07, Ewen Chan a écrit : Yea, I've tried reading the man pages, but it doesn't list all of the options available on there (which would tend to indicate that it is a little behind compared to the development and released versions of OpenSSL). Do you need the '-evp' flag to use '-engine aesni' or they operate independent of each other? And if I'm not planning on coding with the OpenSSL library, but rather just using it to encrypt/decrypt files on my system; then I don't need the '-evp' flag correct? On Wed, Mar 13, 2013 at 12:56 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: Le 13/03/2013 17:17, Ewen Chan a écrit : I'm quite new to openSSL and AES and cryptography as a whole, so please forgive my stupid questions. You then may start by reading the different manpages, then. OpenSSL is a large beast, and you won't do anything useful without reading. I've read that because of the way that the AES-CBC works that it depends on the result from the previous round in order to encrypt the current round that it is inherently not well suited for parallelization; which I am then guessing that it is very possible that it would run (a LOT) slower on GPGPU than it would on an AES-NI enabled CPU. Would that be a fair and safe assumption? That's right. You can achieve better performance with CTR mode, for example. But even there, I doubt you can beat AES-NI. I'm also looking online and through the man pages and it seems like that people are invoking the aesni by using the command: openssl -engine aesni -evp aes-256-cbc ... what's the '-evp' flag for? It means use the EVP interface. EVP is a higher level interface to cryptographic primitives. In the case of AES, it can make use of AES-NI instructions if available. That's useful only if you plan to code using the OpenSSL library. On Wed, Mar 13, 2013 at 12:12 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: GPGPU isn't natively supported. You can write your own engine if you want, but I think memory transfers will dominate the cost. AES-NI is natively supported (I get about 550MB/s on my i5 M540 @2.53 GHz for 8k blocks). -- Erwann ABALEA Le 13/03/2013 16:49, Ewen Chan a écrit : Would it be faster to encrypt/decrypt AES-256-CBC with an AES-NI enabled CPU or would it faster do it with a GPGPU? Does OpenSSL even support GPU acceleration? On Wed, Mar 13, 2013 at 11:44 AM, Ewen Chan chan.e...@gmail.com wrote: Thanks. On Wed, Mar 13, 2013 at 10:56 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: The algorithm Rijndael has some knobs you can turn to tune. The standard AES has these parameters fixed in stone. AES-192 is effectively less secure than AES-256 because of the key length and number of rounds. But less secure may be secure enough. In fact, AES-128 is secure enough for most uses. Number of rounds is important for AES security as it is for any other algorithm (think about attacks on reduced-rounds AES/SHA/whatever). -- Erwann ABALEA Le 13/03/2013 15:31, Ewen Chan a écrit : So the algorithms include the number of rounds? I thought that it would only describe the math process and that it would be independent of the number of rounds (so long as you meed Rijndael's minimum - which is what the current number of rounds is set/default as). I did not know that. Hmmmthanks. Does this mean that a AES-192-CBC is less secure than an AES-256-CBC because of the key length and the number of rounds associated with that; or am I understanding that wrong - that the number of rounds has less-so to do with the security of the algorithm compared to the key length? On Wed, Mar 13, 2013 at 10:24 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: If you change the number of rounds, then it's not AES anymore, but a custom Rijndael. Reading the source code, it appears there's no support for that in OpenSSL (and poking inside an AES_KEY to change the number of rounds probably won't work). -- Erwann ABALEA Le 13/03/2013 14:32, Ewen Chan a écrit : There's a file that I want to encrypt using AES-192-CBC but with 19 rounds rather than the default 12-rounds. Is there a way for me to specify the number of rounds that I would like to use with the AES-192-CBC? (and override the algorithm defaults)? Is that something that I can within the openssl command itself (to encrypt a file) or is the process much more involved than that? And requires programming/scripting? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org
Re: [openssl-users] specifying the number of rounds that I would like to use with AES-192-CBC
Le 13/03/2013 19:10, Ewen Chan a écrit : Wouldn't enabling AES-NI during the encryption/decryption process make it run faster? Of course. So even if I'm just running the openssl command-line executable, processing those files with AES-NI enabled (via '-engine aesni') would be faster than if I left that part out? No. Because AES-NI instructions will automatically be used when available, in your specific scenario. (automatically: you don't have to do anything special to get it) (I'm still a little fuzzy as to whether I would need '-evp' when I use '-engine aesni' or if they work independent of each other.) The man pages doesn't say anything about that (at least not on the man pages online @ openssl.org). The man pages don't go into that kind of detail for the command-line tool (command-line tool: used to do quick stuff, debug things, prototype). Have you tried to encrypt actual files? Have you encountered a CPU bottleneck, a bug, or anything? On Wed, Mar 13, 2013 at 1:31 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: If what you want is simply encrypt and decrypt files using command-line openssl executable, then you don't need to play with engine or evp options. openssl enc uses the EVP interface, which in turn will make use of AES-NI instructions if available (or SSE3, SSE2, SSE, anything available on the runtime platform to speed it up). -- Erwann ABALEA Le 13/03/2013 18:07, Ewen Chan a écrit : Yea, I've tried reading the man pages, but it doesn't list all of the options available on there (which would tend to indicate that it is a little behind compared to the development and released versions of OpenSSL). Do you need the '-evp' flag to use '-engine aesni' or they operate independent of each other? And if I'm not planning on coding with the OpenSSL library, but rather just using it to encrypt/decrypt files on my system; then I don't need the '-evp' flag correct? On Wed, Mar 13, 2013 at 12:56 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: Le 13/03/2013 17:17, Ewen Chan a écrit : I'm quite new to openSSL and AES and cryptography as a whole, so please forgive my stupid questions. You then may start by reading the different manpages, then. OpenSSL is a large beast, and you won't do anything useful without reading. I've read that because of the way that the AES-CBC works that it depends on the result from the previous round in order to encrypt the current round that it is inherently not well suited for parallelization; which I am then guessing that it is very possible that it would run (a LOT) slower on GPGPU than it would on an AES-NI enabled CPU. Would that be a fair and safe assumption? That's right. You can achieve better performance with CTR mode, for example. But even there, I doubt you can beat AES-NI. I'm also looking online and through the man pages and it seems like that people are invoking the aesni by using the command: openssl -engine aesni -evp aes-256-cbc ... what's the '-evp' flag for? It means use the EVP interface. EVP is a higher level interface to cryptographic primitives. In the case of AES, it can make use of AES-NI instructions if available. That's useful only if you plan to code using the OpenSSL library. On Wed, Mar 13, 2013 at 12:12 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: GPGPU isn't natively supported. You can write your own engine if you want, but I think memory transfers will dominate the cost. AES-NI is natively supported (I get about 550MB/s on my i5 M540 @2.53 GHz for 8k blocks). -- Erwann ABALEA Le 13/03/2013 16:49, Ewen Chan a écrit : Would it be faster to encrypt/decrypt AES-256-CBC with an AES-NI enabled CPU or would it faster do it with a GPGPU? Does OpenSSL even support GPU acceleration? On Wed, Mar 13, 2013 at 11:44 AM, Ewen Chan chan.e...@gmail.com wrote: Thanks. On Wed, Mar 13, 2013 at 10:56 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: The algorithm Rijndael has some knobs you can turn to tune. The standard AES has these parameters fixed in stone. AES-192 is effectively less secure than AES-256 because of the key length and number of rounds. But less secure may be secure enough. In fact, AES-128 is secure enough for most uses. Number of rounds is important for AES security as it is for any other algorithm (think about attacks on reduced-rounds AES/SHA/whatever). -- Erwann ABALEA Le 13/03/2013 15:31, Ewen Chan a écrit : So the algorithms include the number of rounds? I thought that it would only describe the math process and that it would be independent of the number of rounds (so long as you meed Rijndael's minimum - which is what the current number of rounds is set/default as). I did not know that. Hmmmthanks. Does this mean that a AES-192-CBC is less secure than an AES-256-CBC because of the key length and the number of rounds associated with that; or am I understanding that wrong - that the number of rounds has less-so to do with the security of the algorithm
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
Re: [openssl-users] Re: possible Bug in OpenSSL - rfc 3161 - TSA service
You should have received an HTTP 400 error, with an HTML page. The service behind it may not be RFC3161 compliant, it may even not be advertised as RFC3161 compliant. Your solution works, but it doesn't answer the problem. -- Erwann ABALEA - québésectophile: séparatiste québécois Le 12/03/2013 20:36, Walter H. a écrit : Hello, I found the following: http://tsa.postsignum.cz:444 produces the following error, when using this as time stamp server with adobe standard/pro BER decoding error what software do they use? my solution with OpenSSL works ... Greetings, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Extra bytes before the decrypted data.
It's probably the IV. -- Erwann ABALEA Le 08/03/2013 16:55, Tayade, Nilesh a écrit : On performing the AES128 decryption, I see the decrypted data is preceded by a block of 16bytes. E.g. Below, 0x48 to 0x5a is the extra 16bytes block. And the actual 'GET' request starts from 0x47 onwards. 48 3f c4 99 fa f0 75 0e 51 b8 3b 58 aa 1f 4a 5a 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a ... 5b 28 c4 52 4e f9 53 2c 08 04 94 04 04 04 04 04 There is a padding of 5bytes in the end, which I can detect. Any pointers on how to detect the initial 16bytes block? This causes the output to be some junk followed by actual data. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Syntax in extension section of openssl.cnf
man asn1parse man ASN1_generate_nconf That should give you some bootstrap information. -- Erwann ABALEA - tridécatabulophobie: peur d'être treize à table Le 28/02/2013 11:16, Walter H. a écrit : Hello, I have the following: --- name = ASN1:SEQUENCE:section [ section ] value.1 = XXX:text --- what is possible to have instead of XXX? Thanks, Walter
Re: [openssl-users] Re: Creating certification requests with no CN and SAN only
RFC5280 was not written by the CAs themselves. The deprecation of CNs in favor of elements found in the SAN extension is logical and comes from CAs as well as browser vendors; CN use has been abused to contain names (human readable), IP addresses, and host names (either simple or fully qualified). Testing for a match between a certificate and the entity that you want to contact is not eased. Browser vendors now push forward name constraints for subordinate CAs, and name constraints don't deal well at all with the idea of lets put everything possible in the CN. SAN can contain clearly labelled dnsNames and ipAddresses, which makes checking much more easier and less error prone. That's better for everyone. For your particular problem, CAs usually ignore extensions you set in your request. To populate the SAN extension, you generally have to provide your elements, aside the request. You still can set a CN in your request, its content will be copied into the SAN. -- Erwann ABALEA Le 14/02/2013 07:18, Matthew Hall a écrit : I am sure at least some would sign it because RFC 5280 PKIX standard was written by the CAs themselves and they are the ones deprecating CN in favor of SAN. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] problem with private extension definitions via oid_section
oid_section = new_oids must be in the top level, not in [ca], [myca], or whatever. Just move that declaration to the top. ICAO has only defined document types 'P' and 'ID', hasn't it? -- Erwann ABALEA Le 13/02/2013 16:46, Eisenacher, Patrick a écrit : I'm troubled by what seems to be a weird problem with private oid definitions in ca.conf. Issuing a certificate works perfectly with the attached ca.conf file, as long as I specify the private extension via its OID in the [ my_ext ] section. When I replace the OID line with the commented out line above it to use the extension's name that was defined before in the [ new_oid ] section, I get the following error: Using configuration from /usr/local/etc/pki/ca.conf Error Loading extension section my_ext 140474292033192:error:0D06407A: asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:109: 140474292033192:error:22074073:X509 V3 routines:V3_GENERIC_EXTENSION: extension name error:v3_conf.c:271:name=documentTypeList Am I doing something wrong or did I stumble over a bug? Why is the OID definition in the [ new oid ] section not being picked up? The command I use to issue the cert is: $ openssl ca \ -config ca.conf \ -batch \ -subj $SUBJECT_NAME \ -startdate $CERT_VALID_FROM \ -enddate $CERT_VALID_TO \ - in $REQUEST_FILE This is with openssl v1.0.0-beta3 on SLES11. Thanks for any insight, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Open ssl 1.0.1c vs 0.9.8g
Because this server is configured to send a self-signed certificate (VeriSign Class 3 PCA). This is useless, and openssl warns you. -- Erwann ABALEA Le 11/02/2013 08:47, Prasanth Madhavan a écrit : Hello Sir, Why does |wget https://www.asb.co.nz| give |Self-signed certificate encountered| error in a system running openssl 1.0.1c and goes fine in a system running 0.9.8g? Does It have anything to do with intermediate certificate? If so how to install the intermediate certificates? Else how to fix this issue? Thanks and Regards Prasanth Madhavan
Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?
Since you need authoritative elements, start by downloading and reading
authoritative documents (all are freely available from ITU-T website).
X.509, section 7:
-
[...]
The issuer and subject fields of each certificate are used, in part, to
identify a valid path. For each pair of adjacent certificates in a valid
certification path, the value of the subject field in one certificate
shall match the value of the issuer field in the subsequent certificate.
In addition, the value of the issuer field in the first certificate
shall match the DN of the trust anchor. Only the names in these fields
are used when checking validity of a certification path.
Names in certificate extensions are not used for this purpose. A
certification path logically forms an unbroken chain of trusted points
in the Directory Information Tree between two users wishing to
authenticate. The precise method employed by users A and B to obtain
certification paths A?B and B?A may vary. One way to facilitate this is
to arrange a hierarchy of CAs, which may or may not coincide with all or
part of the DIT hierarchy. The benefit of this is that users who have
CAs in the hierarchy may establish a certification path between them
using the Directory without any prior information. In order to allow for
this each CA may store one certificate and one reverse certificate
designated as corresponding to its superior CA. The
distinguishedNameMatch matching rule, defined in 13.5.2 of ITU-T Rec.
X.501 | ISO/IEC 9594-2, should be used to compare the Distinguished Name
(DN) in the issuer field of one certificate with the DN in the subject
field of another.
[...]
-
The last sentence is the most important for your answer.
Then follow X.501, section 13.5.2 (with annotations from me):
-
[...]
distinguishedNameMatch MATCHING-RULE ::= {
SYNTAX DistinguishedName
ID id-mr-distinguishedNameMatch }
A presented distinguished name value matches a target distinguished name
value if and only if all of the following are true:
a) the number of RDNs in each is the same;
b) corresponding RDNs have the same number of AttributeTypeAndValue;
[EA: first RDNs are compared together, then second RDNs, etc]
c) corresponding AttributeTypeAndValue (i.e., those in corresponding
RDNs and with identical attribute types) have attribute values which
match as described in 9.4. [EA: order in AVAs isn't important, only
their value once normalized is]
[...]
-
You can further download and read X.520 for exact name comparison rules
(to be able to compare each name element, read the normalization
process, etc).
In case it's not clear, subject and issuer are sequences of RDNs
(RelativeDistinguishedName), and an RDN is a set of AVA
(AttributeTypeAndValue).
If you have a name that is represented as C=DE, O=Siemens, CN=John
Simner, then you have 3 RDNs, and each one has only 1 AVA. C=DE is
the AVA of the first RDN (C is the type, DE is the value).
When an RDN is composed of several AVAs, AVAs are generally separated by
'+' character (instead of ','). For example, C=DE, O=Siemens,
GN=John+SN=Simner, which is equal to C=DE, O=Siemens, SN=Simner+GN=John.
This string representation is only informative.
--
Erwann ABALEA
Le 08/02/2013 16:42, Simner, John a écrit :
Dear All,
I am working on an embedded product which has the OpenSSL 0.9.8w
library and acts as a client.
It is communicating with another product which has the OpenSSL 0.9.8e
library and acts as a server.
A customer has supplied the client certificate for the server and the
associated root CA that signed the client certificate.
The client certificate is installed on the server, the root CA is
installed on the client, and the client is authenticating the server.
Unfortunately, the client is failing the authentication with the error
20 cant find local issuer certificate.
Having spent sometime investigating why this is, I found the server
certificate has the issuer in the form C=... ST=... L=... O=... OU=...
CN=...
and the root CA has the identical string for both issuer and
subject in the reverse order CN=... OU=... O=... L=... St.. C...
As a result X509_Name_cmp fails the comparison.
I thought the ordering of the distinguished name in X509 is
unimportant, yet it appears to be in OpenSSL.
Is this true?
I have trawled the web and found the following statement...
According to X.500, both forms should be acceptable and a
order-insensitive way to compare DN is defined. Unfortunately, looking
up in their keystore for trusted certificates, many libraries compare
issuer DN in the same order they are encoded. This problem affects
especially OpenSSL-based software, which computes hash on DN to speed
up certificate search.
My reason for seeking assistance is to have the facts so that I can
present them to the customer and suggest any restrictions that may be
appropriate to the creation of the certificates.
Thank you for your assistance and I look forward to your
Re: [openssl-users] Re: How to use a binary public key
The 0x00 byte in the BITSTRING is the number of unused bits in the last octet of the encoded bit string. See X.690 as a BER/DER reference. Document is free to download from ITU website. -- Erwann ABALEA Le 24/01/2013 19:17, kap...@mizera.cz a écrit : I have used header from my certificate - it does contain only ASN.1 structure data - unspecific. The structure you can see with openssl asn1parse -in pub-key.der -inform der The added header are simply the first 22 bytes. (not 21 (=18+3) - there is in correctly formated pub-key 1 byte 00h on begin of BIT STRING. Don't know why.) The BIT STRING is yours pubkey.bin. I hope it will help :-) --kapetr Dne 24.1.2013 18:25, Tovey, Dwight (LaserJet RD FW Eng.) napsal(a): On Jan 23, 2013, at 4:18 PM, kap...@mizera.cz wrote: I have build the whole pub-key (in DER) from yours pubkey.bin by adding public key header - as wrote w...@omnigroup.com If I did not make error, it could work now - try it. It is in attachment. openssl asn1parse -in pub-key.der -inform der -strparse 18 and you will see the same as by parsing yours pubkey.bin. To see whole public key structure: openssl asn1parse -in pub-key.der -inform der --kapetr This worked. I translated the .der key into PEM format, which I was then able to load into my python script with M2Crypto.RSA.load_pub_key(). I could then use the resulting RSA_pub object to encrypt my data and send it to the device. So, my next question is, how did you add the public key header? What does this header look like? If I know that then I should be able to add it within my script and handle it all directly. Thanks Dwight Tovey Laserjet RD Engineer dwight.to...@hp.com (208)396-4645 __ 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 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] OpenSSL: RC4 and IDEA algorithms
Camellia is freely available on several licenses (BSD, GPL, MPL). IDEA's patent has expired (2011 un Europe, 2012 in Japan+USA). RC4 is an RSA trademark, no patent has been asked on the algorithm itself. RC5 is still patented, by RSA. -- Erwann ABALEA - aquadiemoctus: aujourd'hui (oui, je sais, celui-là est particulièrement capillotracté) Le 23/01/2013 17:36, sarju tambe a écrit : In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. In README file, for RC4 we need to take RSA Security's permission. IDEA algorithm is patented by Ascom and they should be contacted if that algorithm is to be used. Here I have queries: 1. In OpenSSL RC4 and IDEA are not disable so do we need to take separate permission to use them? if yes, then do you have any idea as to how to get the permission? please correct me if i am wrong. Thanks, Sarju __ 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] Possible bug in verifying a certificate if default root store is configured
Inline. -- Erwann ABALEA Le 07/12/2012 11:26, Ralph Holz a écrit : Hi, Yes, that clarifies the issue for me. One thing I am wondering about now (as a user) would be how to get openssl to disregard any local trusted cert list - i.e. how do I get it to act on the provided CAFile only? openssl command -CAfile myfile -CApath /nonexistent should do it. Do I need to remove the complete local root store? Or can I set the CAPath to . and then openssl will not fall back to default settings? Setting -CApath to '.' works also. I think that information is what users are really looking for. Ralph On 12/06/2012 09:32 PM, Chris Palmer wrote: On Thu, Dec 6, 2012 at 12:00 PM, Erwann Abalea erwann.aba...@keynectis.com wrote: There's the same behaviour with -CAfile. If -CAfile isn't specified, then the default platform CA file is used (by default, /usr/lib/ssl/cert.pem). This is true for verify, ocsp, smime, and cms. Oh, right. New diff attached. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Possible bug in verifying a certificate if default root store is configured
Bonjour, See apps/apps.c, function setup_verify. It receives 2 arguments CAfile and CApath. Each one is processed independently, and if either one is NULL, its corresponding default is used. -- Erwann ABALEA Le 06/12/2012 10:38, Ralph Holz a écrit : Good day, I was using openssl verify as described in the Pastebin link to validate a cert, using a custom root store indicated with the -CAfile option. The custom root store contains a Comodo root, the cert to be validated is signed by Equifax. The expected result would be for that check to fail. However, it does not: it verifies with OK. This happens on Ubuntu and very likely also on Fedora, which makes me think it might be an upstream issue. Both OS have default root stores configured for openssl. I would like to ask for confirmation from this ML if this kind of behaviour is unexpected as I would expect -CAfile to overwrite any default root store: http://pastebin.com/3CZHbKYg https://bugzilla.redhat.com/show_bug.cgi?id=884305 Am I missing something or is this a bug? If it is a bug - this would mean you verify against your distro's root store even if you think you have chosen your own roots only. Also, would the same thing happen if you use libssl-dev? Thanks for any clarification on this issue. Thanks, Ralph __ 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] Possible bug in verifying a certificate if default root store is configured
There's the same behaviour with -CAfile. If -CAfile isn't specified, then the default platform CA file is used (by default, /usr/lib/ssl/cert.pem). This is true for verify, ocsp, smime, and cms. I personally don't think it's unexpected for the openssl app. I'd even like it to be extended to other parts (ts, s_client, s_server, ...). Documented, of course. But only for the app. -- Erwann ABALEA Le 06/12/2012 20:39, Chris Palmer a écrit : On Thu, Dec 6, 2012 at 2:16 AM, Ralph Holz ralph-openssl-...@ralphholz.de wrote: -CAfile fileA file of trusted certificates. The lookup first looks in the list of untrusted certificates and if no match is found the remaining lookups are from the trusted certificates. The root CA is always looked up in the trusted certificate list: if the certificate to verify is a root certificate then an exact match must be found in the trusted list. This has led me to believe -CAfile would cause openssl to ignore a default path to certs. I am surprised CAPath is still evaluated if you indicate a CAFile. However, as strace shows: I've attached a diff against HEAD for verify.pod. Is it any good? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Openssl not properly validating certificates?
OpenSSL 1.0.1 works fine here, both with expired and revoked certificates (i.e. correctly reports the status). Could you share your elements (certs, CRLs)? -- Erwann ABALEA - chlorophytophonie: musique pour les plantes vertes Le 05/12/2012 15:11, Will Nordmeyer a écrit : Hi, I've done some googling and failed to come up with an answer... I have openssl 1.0.0-25 (also seeing it as 1.0.0-fips) installed on a test server running CentOS 6.3 (2.6.32-279.14.1.el6.x86_64). It is the latest one avaialble from the CentOS repositories. I've downloaded and set up several Certificate Authorities as trusted certs and their accompanying CRLs. I've created the hash links for the CRLs and CAs as well. When I run a test on some test certificates I received, they all come back OK, even though some are expired and some are revoked. I've run the following verify command and expected different results to flag TestOne as valid, TestThirtySeven as Revoked and TestForty as expired. I also tried crl_check_all and purpose flags, with no different results. [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestOne_Valid.pem TestOne_Valid.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestForty_Expired.pem TestForty_Expired.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestOne_Valid.pem TestOne_Valid.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestForty_Expired.pem TestForty_Expired.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK [root@dmapsdev01 TestCerts]# Similarly, when I run from a browser, with tomcat configured for CRL checking (using APR tcnative), tomcat lets the expired and revoked certificates pass. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Question about exporting user certificate files to .pfx
Can you post here the certificate chain? Not the private key, only the certificates, from the root down to the end-entity. -- Erwann ABALEA - Ca se fait pas du tout d'avoir donné toutes les adresses email des votants C bon pour les spammers ça ! [suit la liste intégrale des votants mal quotée] -+- AN in Guide du Neuneu Usenet : bien suivre sa logique -+- Le 19/11/2012 16:53, Deeztek.com Support a écrit : I fixed the command and it created the end user .pfx file. It imported successfully into windows but I get this message when I looked at the certification chain for the intermediate ca: This certification authority is not allowed to issue certificates or cannot be used as an end-entity certificate. Any idea why I would get this? or would it affect anything? On 11/19/2012 10:47 AM, Dr. Stephen Henson wrote: On Mon, Nov 19, 2012, Deeztek.com Support wrote: Nevermind the last message, you said *concatenate* the CA certificate together. So, this is what i did: Root cert: cat ca.crt cachain.pem Int-ca cert: cat int-ca.crt cachain.pem Ran the following but it didn't work: openssl pkcs12 -export -out someone.pfx -inkey someone.key -in someone.crt -certfile cachain.pem -passout:somepassword If you used that exact command the -possout syntax is incorrect. It should be -passout pass:somepassword 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 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] Re: Question about exporting user certificate files to .pfx
Thanks. The first certificate is your root CA, the second one is a version 1 certificate that can't be used as a CA (it would be insecure to allow it). If your end-user certificate is issued by this second certificate, then the error message is normal. -- Erwann ABALEA - anatomie: ablation chirurgicale du canard Le 19/11/2012 18:48, Deeztek.com Support a écrit : I'm assuming this is what you want. This is the contents of my chain file: -BEGIN CERTIFICATE- MIIFlDCCA3ygAwIBAgIJAJsm0MjspJZLMA0GCSqGSIb3DQEBBQUAMDoxGDAWBgNV [...] VSjVBAcgfCJGH/rHJyOIA/xL3QrfAGMrdWaupIVgLWtBZvOrbOpLMQ== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIE8DCCAtgCAQEwDQYJKoZIhvcNAQEFBQAwOjEYMBYGA1UEAxMPY2EzLmRlZXp0 [...] LMJHeiywxLvyFl6uPSjjMjTzcXk= -END CERTIFICATE- On 11/19/2012 11:26 AM, Erwann Abalea wrote: Can you post here the certificate chain? Not the private key, only the certificates, from the root down to the end-entity. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Question about exporting user certificate files to .pfx
Answers inline. -- Erwann ABALEA - Un forum peut répondre à plusieurs besoins à la fois Ici, le groupe des débutants dépasse en nombre le groupe des utilisateur middle-class ce qui provoque inévitablement des tensions. -+- EF - Guide du Neuneu d'Usenet - La lutte des middle classes -+- Le 19/11/2012 19:47, Deeztek.com Support a écrit : Maybe I got something wrong creating the intermediate CA which is supposed to be the 2nd certificate. This is what I did to create the intermediate CA. Maybe I missed something? Generated Intermediate CA key: openssl genrsa -out ia.key 4096 Generated Intermediate CA Certificate Request: openssl req -new -key ia.key -out ia.csr Processed Intermediate CA request and signed by the CA: openssl x509 -req -days 1825 -in ia.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ia.crt There's no mention of the extensions you put in your intermediate certificate. It may have magically worked, if the openssl configuration file had been properly filled. The default configuration file doesn't set any extension when you create a certificate with openssl x509, whence version 1. You should get better CA scripts, or build your own set after reading your openssl.cnf file and other associated documentation. man req man x509 man ca man x509v3_config When I need a junk CA, I personaly use openssl req to create the root, and openssl ca for all other certificates (intermediate CAs or end-entities). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Usage of d2i_RSA_PUBKEY function!!
Your RSA public key is not pure DER encoded, it's DER+base64 encoded.
d2i_* functions take pure DER objects (binary on the wire).
--
Erwann ABALEA
-
multicoprothalassotope: station balnéaire de la Méditerranée
Le 16/11/2012 15:37, PraveenPVS a écrit :
Hi,
I need to load RSA Public key which is stored in the char buffer. I came
across d2i_RSA_PUBKEY function to do the same (Please correct me if I am
wrong here).
When I use this function, RSA Public key is not getting loaded.
In the main, i have the following function call:
loadRSAPubKey(MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0yepYbVklwYuwGEmenQhVwyddHGdM26rZqWG5tFFPYz1QA51EJ44thSejrbRKHqV/EmqU8wwuFeaDmxnVz6UhG3HfjuTbAkkuZ+boEIealr/Ml+kHqRgzQ6G1rP9+5goboZzlpB9b8zYvp+5my5xFCd8OqyoKKyoHBJ3Tf0NCSstow7k0W/5JMeDa844HpCK4rOxlUaIGsDGTC/XIJ93EQs8yT4js5iw++pJslQvh1RzeQtzLQ8xNGYKlr9RyIvh2S28qXb+qfEx7r+kG8RjS4jc3E3XR/nja7HXnAFWCgF/cRcj5aQHq02scW8Vi+iBS/A1Y5RD2QMxJqY1yxC28QIDAQAB);
int loadRSAPubKey(char *key)
{
const unsigned char *p = key;
int keylen = strlen(key);
prsa_loaded = (RSA *)d2i_RSAPublicKey(NULL, p, keylen);
if(!prsa_loaded)
{
printf(Failed to load RSA key\n);
exit(0);
}
return 1;
}
It was always saying Failed to load RSA Key and exiting...
Am i missing something here??
Could you please help me out.
Thank you.
regards
Praveen
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certool v.s. openssl - broken/mis-interpreted sha256 cert issue.
In addition to Mr Henson answer, your CA certificate doesn't have any keyUsage extension, depending on the toolkit it may not be considered a valid CA. Your countryName AVA is wrong, too. It must be only 2 characters long, NL in your case. -- Erwann ABALEA - yuppiexpédidétritus: cadavres gelés de grimpeurs occidentaux jonchant l'Everest parmi les yakocoprolithes Le 14/11/2012 19:16, Dirk-Willem van Gulik a écrit : On 14 nov. 2012, at 18:42, Dirk-Willem van Gulik di...@webweaving.org wrote: Have a CA (created by certtool, validates in openssl as self signed just fine) and a server cert (created with certtool, signed with certool) which des NOT validate in openssl. However the signature (when extracted with openssl its asn1parse; openssl its rsautl and openssl its sha256) looks correct. And it seems to be accepted by the NSS and apple their stack. As well as java its native and bouncy-castle stack. So this starts to feel a bit like a openssl bug. Any suggestions? Not unlikely this is sha256 specific - as that is what triggered this. Tried against 1.0.1c and 0.9.8q (with the latter of course not do the SHA256). Thanks. Dw. $ openssl verify -CAfile ca.pem ca.pem ca.pem: OK $ openssl verify -CAfile ca.pem x.pem x.pem: O = MedVision360 Test Org, CN = svc01.local error 7 at 0 depth lookup:certificate signature failure 140735152787932:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175: 140735152787932:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Which errors out. Extracting the signature manually with $ openssl asn1parse -in x.pem -out x.sig -noout -strparse 828 $ openssl x509 -in x.pem -pubkey -noout x.rsa $ openssl rsautl -in x.sig -verify -asn1parse -inkey x.rsa -pubin $ openssl asn1parse -in x.pem -out x.tbs -noout -strparse 4 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT:sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING - 73 87 b0 9d e8 15 9f fb-ce af 3d ef 18 33 b3 04 s.=..3.. 0010 - 28 64 b5 85 e9 88 91 69-e9 74 2a e6 45 ea 63 62 (d.i.t*.E.cb $ openssl sha256 -c x.tbs SHA256(x.tbs)= 73:87:b0:9d:e8:15:9f:fb:ce:af:3d:ef:18:33:b3:04:28:64:b5:85:e9:88:91:69:e9:74:2a:e6:45:ea:63:62 looks actually good. As does the ANS1 it seems __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] I can't believe how much this sucks
Answers inline. -- Erwann ABALEA - paléocapridé: genre de vieille bique, cf paléotalpidé (vieille taupe) ou paléogadidé (vieille morue) Le 13/11/2012 19:34, Sanford Staab a écrit : I have been struggling with openssl for a few months now writing batch scripts on windows trying to make a .net web client with a client certificate work with 2-way ssl against an apache web server. So you've looked at Apache documentation in addition to OpenSSL doc, right? Do you guys just want to continue to answer questions on this alias and not FIX the docs somewhat over time? I could go into a litany of how much information is just missing from the docs with INCOMPLETE everywhere. (see this link http://www.wolmarans.com/drupal/?q=node/22 for one of the 900k+ hits on a google search of “openssl+docs+suck” for how much hell you guys are putting people through trying to figure out this tool) openssl is used all over the world by tons of people (so I feel dumb having problems here – but I know from Google I am not alone.) but it is just *unbelievable* to me that the docs remain so terse and useless for so many years. I have sent email to this alias previously asking how I can help with this. It seems to me there should be an openssl docs forum where content from this eventually finds its way into the online docs themselves. A tool is only as good as people are able to use it. So let me get specific here – one simple specific question (of many that I have) that has me clueless: The command of: openssl s_client -connect www.pawnmasterpro.com:443 -CApath ssl\certs -cert ssl\certs\client_1.crt -key ssl\keys\client_1.key -pass file:ssl\keys\Client_1_pwd.txt results in output containing: No client certificate CA names sent That's a warning. OpenSSL client warns you that your Apache server hasn't sent any CA name to the client to help decide which certificate it should present. That's the result of your Apache configuration. from the docs for the s_client command, –cert option says: **-cert certname** The certificate to use, if one is requested by the server. The default is not to use a certificate. *My guess from this is that this command is referring to the CLIENT SSL certificate - no? *If my assumption is correct, then why am I getting this error? Or is this a notification of something normal and I should be looking elsewhere? This isn't an error, and OpenSSL has tried to present the certificate you asked it to. I have checked the Apache httpd-ssl.cnf file I am using and verified that all the certificate related parts are filled in and I have verified the integrity of all the certificates referenced by it. I have been able to do straight one-way SSL with the server as well with both IE and Chrome browsers. Two-way SSL fails with the server logs indicating that the client “refused” the connection. I am using a self-signed CA which was used to sign the server certificate. The client certificate is also signed by the same CA self-signed certificate. Apache error logs give me this: [Tue Nov 13 12:38:56 2012] [error] [client 127.0.0.1] Invalid method in request Which is about as useful as the openssl docs are. It indicates Apache didn't receive a valid HTTP request. That's not OpenSSL's job. Right now (19:29 UTC), your server doesn't do TLS, only plain HTTP on port 443. Trying to do TLS on such a server might give this error message in your Apache. I am also seeing this in openssl’s s_client output: verify error:num=19:self signed certificate in certificate chain From what I think I understand, this should not be a showstopper problem as all root CA certs would naturally be self-signed no? Full output of this operation with the –showcerts command is attached for reference. I have read through many forum examples of how to do this and it seems simple enough but then when it doesn’t work, figuring out what things MEAN and how to address what is wrong proves to be be very difficult indeed. Having read the provided output of your tests, it seems you configured your Apache server to send both its own certificate and the root as intermediate certificates. That's both wrong and useless. OpenSSL s_client tells you that he found a self-signed certificate in the returned chain (which is true). Disable the SSLCertificateChainFile directive in your Apache, it should get better. Anyway, the output shows that the TLS connexion went OK, and that Apache received something that looked like a valid request. Go read Apache doc again.
Re: [openssl-users] Re: Find the difference in (milli|micro)seconds between two ASN1_TIME values
Le 07/11/2012 16:08, Jakob Bohm a écrit : On 11/7/2012 3:39 PM, Charles Mills wrote: A struct tm is only granular down to whole seconds, right? Yes, and it is not the easiest data type for data math either, even when restricted to GMT/UT1/UTC. Plus many OS/compiler supplied struct tm related functions work badly outside the range 1970 to 2037 (U2K38 bug and signedness issues). What would be really nice would be a function that converted the time to/from a signed bignum (OpenSSL type BN) of nanoseconds since 1970-01-01 00:00:00.0 GMT/UT1/UTC, counting GMT/UT1/UTC virtual seconds not IAT SI seconds (so an input timestamp of 2012-06-30 23:59:60 would be counted as 2012-06-30 23:59:59 or 2012-07-01 00:00:00 and the straigt subtraction between 2012-06-30 23:59:00 and 2012-07-01 00:00:00 would be 1 hour (3600 seconds), not 3601 seconds). Such a function would be useless. There's only 60/61s between these 2 dates, not 3600/3601 ;) I guess you also mean counting in TAI/POSIX seconds, since these don't include leap seconds, right? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Reference material on how to do certificate validation with OpenSSL
Where's the failure here?
hostname_matched is set to HOSTNAME_VALIDATION_ERR at initialization,
and in case of a NULL hostname or certificate it is returned by the
function, unmodified.
--
Erwann ABALEA
Le 27/10/2012 21:00, Jeffrey Walton a écrit :
On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:
Hi everyone,
iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html
It is not trivial and so I thought this reference material could be
useful to people on this mailing list.
] int validate_hostname(char *hostname, X509 *server_cert) {
] int hostname_matched = HOSTNAME_VALIDATION_ERR;
] if((hostname == NULL) || (server_cert == NULL))
] goto error;
] ...
] error:
] return hostname_matched;
] }
You failed open rather than closed. Its not a good choice of
strategies for high integrity software.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Reference material on how to do certificate validation with OpenSSL
Bonjour, In the 4.2 paragraph, talking about revocation, you explicitely write that your code examples don't check for revocation. Depending on your target audience, this might not be a wise choice. In the same part, you're referring to a post by Ben Laurie about how hard it is to detect revoked certificates, and thus how useless it is to revoke a certificate, because applications don't check for revocation, or do it with a soft-fail behavior. That's something public CAs want to be changed, and the lack of revocation check in your examples won't help. -- Erwann ABALEA Le 27/10/2012 17:00, Alban D. a écrit : Hi everyone, iSEC Partners just released a paper that provides detailed guidelines and sample code on how to properly do certificate validation with OpenSSL: http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html It is not trivial and so I thought this reference material could be useful to people on this mailing list. Thanks, Alban D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
Strange, my previous answer was sent empty, and every try results in an empty mail stored in my postponed folder... Anyway. Use decimal numbers for an OID. Yours will be 2.25.266774424501754920443129542379924997403 And for your policyIdentifier, it should be easier to read if expressed as company_root_oid.2.5.29.32.1. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
Bonjour,
Le 28/09/2012 16:29, Valentin Bud a écrit :
On Fri, Sep 28, 2012 at 02:53:35PM +0200, Erwann Abalea wrote:
Strange, my previous answer was sent empty, and every try results in
an empty mail stored in my postponed folder...
Anyway.
Use decimal numbers for an OID.
Yours will be 2.25.266774424501754920443129542379924997403
How did you transform the number from hex to decimal? I have been
looking to do this for an hour now to no avail.
Thanks for giving me the number.
(echo ibase=16; echo c8b2e2a0094b11e2936a0002a5d5c51b | tr 'a-f'
'A-F') | bc -l
Still it doesn't work. Another error now. But first, the changes I have
done are as follows:
openssl.cnf
===
# This is at the beginning of the file
company_root_oid = 2.25.266774424501754920443129542379924997403
[ company_ca_policy ]
policyIdentifier = company_root_oid.2.5.29.32.1
My fault here.
I'd use:
-
oid_section = new_oids
[ new_oids ]
company_root_oid = 2.25.266774424501754920443129542379924997403
acceptable_cp = ${company_root_oid}.2.5.29.32.1
[ req ]
distinguished_name = mydn
[ mydn ]
[ company_v3_ca ]
certificatePolicies = @mypolicy
[ mypolicy ]
policyIdentifier = acceptable_cp
-
Some pieces are still missing there, but with the command line you used
below, with the addition of a -subj '/C=XX/O=Company/CN=Company Root',
you'll have a certificate.
Since you're new to PKI, I don't think you've already created and
populated the .2.5.29.32 branch of your OID arc, and I'm guessing you
took this 2.5.29.32 from the RFC. If yes, forget about it and organize
your OID arc the way you want. For example have a .1 for all your
certificate policies, and dedicate one for the CP you want to declare here:
allcompanyCP = ${company_root_oid}.1
CPforwebservers = ${allcompanyCP}.1
and use CPforwebservers as the declared policyIdentifier.
[ company_v3_ca ]
certificatePolicies = ia5org,@company_ca_policy
===
The error is the following:
wiz:CA/ (master) $ openssl req -new -x509 -days 3650 -extensions
company_v3_ca -keyout private/company.ca.key -out certs/company.ca.pem -config
openssl.cnf
Error Loading extension section v3_ca
6198:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too
large:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/asn1/a_object.c:109:
6198:error:2208306E:X509 V3 routines:POLICY_SECTION:invalid object
identifier:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/x509v3/v3_cpols.c:211:section:company_ca_policy,name:policyIdentifier,value:company_root_oid.2.5.29.32.1
6198:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/x509v3/v3_conf.c:93:name=certificatePolicies,
value=ia5org,company_ca_policy
The OpenSSL version, if it matters is:
wiz:CA/ (master) $ openssl version
OpenSSL 0.9.8r 8 Feb 2011
I don't know what I am doing wrong. PKI is a vast topic with a lot of
things to grasp. I have to take it slow.
I do have one question though. In the link that Ryan Hurst suggested the
policyIdentifier is left out.
What is the difference between the two? Would I be RFC compliant if I
would use a policyIdentifier or none at all or it doesn't matter?
For a root certificate, the certificatePolicies extension is generally
of no use. Some entities ask for this extension to be absent.
The normative validation algorithm doesn't take into account any
extension from the trust anchor (your root is a trust anchor), but some
implementations could eventually look at these and set parameters (used
by the algorithm). You may want to dig into RFC5280 section 6 or X.509
section 10 if you want to know more about it. Beware, it's insane.
I have read somewhere that some applications cannot parse UUIDs. If
using a certificate policy without a policyIdentifier would keep me RFC
complaint I would choose to do that. I don't want to get in trouble with
applications.
This has nothing to do with UUIDs here, as the relying party won't have
to parse this OID, it doesn't need to have any structure. The UUID is
used here to have a unique OID arc.
Acquiring an OID for the company is not possible, at least for now. I
guess that would be the most elegant solution.
It's always possible to get a private OID in the 1.3.6.1.4.1 branch.
Just send an email, and you'll have one.
Depending on your country, you may even already have one, based on your
company's unique registration number.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Error while parsing x509 certificate using ecdsa-with-SHA256
Bonsoir, Your public key parameter field is set to NULL. It must either be an OID to name the curve, or explicit parameters. -- Erwann ABALEA Le 26/09/2012 14:17, Naveen Gopala Reddy a écrit : Hi, I am using openssl version 1.0.1c to parse the attached certificate(test.pem) using the below command. $ openssl x509 -in test.pem -text However, I get the following error + Unable to load Public Key 3077577480:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode error:ec_ameth.c:178: 3077577480:error:100D7010:elliptic curve routines:ECKEY_PUB_DECODE:EC lib:ec_ameth.c:206: 3077577480:error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public key decode error:x_pubkey.c:164: + Could you please help me debug the same. Thanks and regards, Naveen __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Le 25/09/2012 18:45, Jakob Bohm a écrit :
On 9/25/2012 6:12 PM, Erwann Abalea wrote:
Le 25/09/2012 14:16, Jakob Bohm a écrit :
On 9/25/2012 11:11 AM, Erwann Abalea wrote:
[...]
Any signature algorithm works by dividing the universe of N bit strings
into those that are validsignatures for the object and those that are
not. For most algorithms the valid subset is exactly one of the 2**N
bit strings, for some ECC variants it is two of them, for DSA it is
2**(N/2) of them. [...]
I'll have to re-read this in a quiet environment, with my HAC kept
close. Thanks.
[...]
So there's one more possibility: the CA changes its key, keeps its name
(so it's the same CA), and issues 2 certificates. First one is a
self-signed one with its brand new key. Second one is a self-issued one,
signed by the previous key.
Both this case and the previous one are used by several countries for
CSCA certificates (for passports).
So you say they have an intermediary certificate where
Issuer DN==Subject DN,
but the Issuer keyis not the key in the cert itself. Very weird, unless
there are appropriate key identifiers in thecertificates.
That's right. And that's precisely a self-issued certificate, considered
differently on the validation algorithm. For example, such a certificate
doesn't count for the pathLen constraints.
{subject,authority}KeyIdentifier extensions are not mandatory.
Consider a root CA with a self-signed certificate, with only
digitalSignature set in its keyUsage extension. This CA can then
self-issue another certificate with the cRLSign bit set. That's
different from a CA with 2 self-signed certificates, each one for one
usage. The former is valid for RFC5280 while the latter isn't, both are
valid for X.509.
[hours later]
Another scenario has been used in real world: have the root certificate
contain the hash of the public key of the next root (etc), the subject
name doesn't change. That was used for SET (shortly, I admit), as all CA
certificates were renewed every year. Some kind of forward chaining.
Some of the discussions on this thread seems to indicate that when
both the
A and B certificate are available, OpenSSL sometimes may fail to stop
when
it hits the new (A) CA in the trust store because it does not
distinguish between
its trust store and its collection of cached/preloaded intermediary
certificates
(unlike Windows, which has seperate stores for those two categories).
What I understand from the OP seems to be different from this paragraph.
I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed
version 1996-2028 (same key, same name). That's your scenario 1.
The Thawte CA certificate doesn't have any authorityKeyIdentifier
extension, and OpenSSL correctly tests each possible certificate,
filtered by their subject name, until the validation is OK.
I assume the Thawte certificate you mention is not the same as the
VeriSign certificate (they havebeen the same company for a long time
now).
The OP talked about www.google.com, I connected and got a 1024bits
intermediate Thawte certificate from 2004, signed by VeriSign C3.
--
Erwann ABALEA
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Bonjour, Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. This needs a manual update of the trust store, as you're introducing a new certificate object not linked to anything. Following X509 rules, you can also change the key. Following RFC5280 ones, you can't (in fact, you can, but it won't be the root of the same PKI). 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the certificate validation could SHOULD (but might not) match issued end entity certificates to the trust anchor by also comparing signatureAlgorithm in the issued certificate against subjectPublicKeyInfo.algorithm in the candidate issuer cert from the store. The issued certificate will have sha1withRSA or sha256withRSA in its signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096. A SHA256 certificate (or however you call it) can still produce sha1withRSA signatures. The other way is also possible, of course. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Bonjour, Le 25/09/2012 14:16, Jakob Bohm a écrit : On 9/25/2012 11:11 AM, Erwann Abalea wrote: Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. And in fact, OpenSSL works correctly, at least versions 1.0.1 (Ubuntu), and 1.1.0 (from sources). The 1.0.1 version displays a warning if it finds the expired certificate first, but the verification goes on with the next certificates, and it finally gives an OK result. That can be checked either by removing the nonexpired certificate from the CAfile or by changing to the CApath mode and using strace to see OpenSSL opens the second CA certificate (named 415660c1.1). When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. Read carefully, I said that if the only way to pick the right candidate is to validate the signature against 2 same-algorithm public keys, then the security of the signature validation is reduced by up to log2(keycount) bits. ?? Could you elaborate on this? Anything that can be filtered out without signature checking (such as different algorithms, different key identifies, different key lengths etc.) does not cause that problem. And is OK security wise, but may not be implemented by all (otherwise compliant) X.509 implementations. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. Cross-certifications involve different distinguished names for signature chain building, these can all be verified by building the trusted chain before validating the signatures. You're right. The cross-certified entity will have different certificates, each one with a distinct issuer name. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. Yes, but it will still have a sufficiently close name to retain any reputation based human trust. What about the DigiCert (Malaysia) against DigiCert, Inc (US) not so old problem? B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. Actually, this is a cross-certificate from the old CA to the new CA. as you said, well described in the literature. Again, I misread. The case you're describing is really a cross-certificate. So there's one more possibility: the CA changes its key, keeps its name (so it's the same CA), and issues 2 certificates. First one is a self-signed one with its brand new key. Second one is a self-issued one, signed by the previous key. Both this case and the previous one are used by several countries for CSCA certificates (for passports). Some of the discussions on this thread seems to indicate that when both the A and B certificate are available, OpenSSL sometimes may fail to stop when it hits the new (A) CA in the trust store because it does not distinguish between its trust store and its collection of cached/preloaded intermediary certificates (unlike Windows, which has seperate stores for those two categories). What I understand from the OP seems to be different from this paragraph. I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed version 1996-2028 (same key, same name). That's your scenario 1. The Thawte CA certificate doesn't have any authorityKeyIdentifier extension, and OpenSSL correctly tests each possible certificate, filtered by their subject name, until the validation is OK. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256
Re: [openssl-users] converting text to pem
Bonjour, Le 17/08/2012 09:33, kiran Palli a écrit : Hi, I generated an rsa 2048 key-pair with these commands: openssl.exe genrsa -F4 -out key.pem 2048 openssl.exe rsa -text -in key.pem key.txt Now I lost the key.pem file and also lost the key.txt in its original format. That's sad. 2 files lost at the same time? And you weren't taught to take care of these? They weren't important, were they? Why don't you just throw that key away and pick a new one? But I have private exponent and public exponent from the text file. Those were enough for my tool suite to sign a binary file and then verify. Now I need to test something with openSSL signing, but how do I recover the private key in .pem format (key.pem)? Looks like homework. Did you ask Google? This is the left over portion of key.txt(example, but a valid key-pair): Private-Key: (2048 bit) modulus: |00:f3:5a:8f:46:08:11:d8:f7:65:eb:26:8f:e6:fe: [...] d2:61 | publicExponent: 65537 (0x10001) privateExponent: |73:e4:bd:f4:e1:24:f6:ca:23:7c:90:99:d9:ad:9c: [...] 11| Using bc you can quickly get p, q, dp and dq. qinv is harder to get, but it's possible. -- Erwann ABALEA
Re: [openssl-users] OpenSSL OCSP
Le 16/08/2012 18:38, adrien pisarz a écrit : Ps: does anyone know why the engine option is not available with ocsp and the private key must be in a file instead of store securely in a HSM ? As said by Dr Henson, this is only a testing tool, not a production service. If you need a production-grade system, you'll have to write your own using the API. -- Erwann ABALEA
Re: [openssl-users] OpenSSL OCSP
Bonjour, Answers inline. -- Erwann ABALEA Le 14/08/2012 19:03, adrien pisarz a écrit : Hi, I have several questions about the ocsp functionnality. I read many articles before asking those questions and unfortunetaly I still don't have the answers. Maybe you can help me. Fist of all, here is my ocsp configuration : openssl ocsp -index index_prod.txt -CAfile OpCA.pem -rsigner ocsp.crt -rkey ocsp.key -port 3456 -text -out /home/userocsp/ocsp_responder.log The file index is populated by a self-made script, the ocsp.crt (resp. key) is a certificate (resp. key) which contains the ocsp signature extensions the OpCA.pem contains the subAC certificate Here are my questions : 1. Why the ocsp client work only if the -VAFile is set and otherwise I got a signature error ? Is there a way to solve this issue ? Maybe because the responder is not one of: - the CA that signed the certificate you're requesting the status on - a designated responder directly signed by the CA that signed the certificate you're requesting the status on Reread RFC2560. If you're instanciating the third possible responder type (trusted responder whose public key is trusted by the requester), then you obviously need to inform the client/requester. You didn't provide elements on who signed who, so that's just a guess. 2. If I wan manage several subAC should I open a port foreach subCA ? With the command-line tool, yes. If you need to have more CAs, then you could probably try something more suited than the command-line tools. The command-line tool also doesn't respond to GET requests, only POST ones. 3. Why the ocsp responder requires that all the certificates (even the valide's one) must be present in the index.txt in order to provide a correct answer ? I was expected that openssl will check the certificate signature and if the serial is not present in the index.txt, it will answer good and not unknow. Design choice. You're giving the responder a database, so it supposed to know *all* the certificates. OCSP can be based on CRLs (black-list), but that's not implemented by the tool. If that's what you want, you'll have to write your own. 4. As said, the openssl responder is working but a IHS server is not abble to validate his answer and I got those errors : [...] Does anyone know how to configure an IHS with an openssl ocsp responder ? You may ask your provider for this, not OpenSSL.
Re: [openssl-users] Weird not-so-self-signed certificate
Bonjour, The given certificate is correctly self-signed, you can manually check it by extracting the signature block and playing with openssl rsautl ..., dd ... | openssl dgst -sha1, etc. It fails the validation path check probably because it's not declared as a CA. There's some ongoing work on IETF about DANE certificates and clarifications on RFC5280 about self-signed EE certificates. The presented certificate is certainly such a DANE one. -- Erwann ABALEA - pastacircopyge: quelqu'un qui a vraiment beaucoup de chance Le 06/08/2012 13:04, Johannes Bauer a écrit : Hi list, I'm quite puzzled and hope somebody can help me. I'm handling a large number of certificates and for generating testcases for the software I employ, I wrote a small script that downloaded web server certificates en bulk and then processed them, to check for irregularities. My software barfed on a certain certificate, which is this one: -BEGIN CERTIFICATE- MIIC8TCCAdmgAwIBAgIQNmL4pIUXFpRBUK7QhJR/JjANBgkqhkiG9w0BAQUFADAg MR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFHSjgwHhcNMTAxMjIzMjAzOTU0 WhcNMjAxMjIwMjAzOTU0WjAgMR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFH SjgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6CNzdS+lWquEQndmY R1XY6cEqeMSB6YVSxXFAARRsdLQceCIpZbD5CijYklx874gOokTwSzZ7EJ6QSPUL jItM5PRlkeh0twrVEU5UTeqybAnVEciL5oVy6EPm4niYweAJrf5QCtPcORtt2Kjs xYAX2Ltl7mjvi+QM+XwDX0LKWyIjpYTZXB/5XRnpzUuBw3pDx+z4fWk8SFqN4Ptb /7fZSoxI6VeuTvrgS4aMyjsPylPnpXVAFYOcxketS0D1F9m0z5t3eD3hXesgbCHS svy0gACF3qvarJiE6MVDaJ/tlX408G9V3gEHpCCrk+yL5FiT/dtr7tNlWMt+o9D4 5/kNAgMBAAGjJzAlMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwQHAwUAsAAA ADANBgkqhkiG9w0BAQUFAAOCAQEAYvuUspk2lHiP3IM4maY2DOH0UfSsldyqOICP ue3xmqNnkhN7QBe8GIcsKt3fiozC7L+zcxdIY6L7WgGx1+aK8f3AKl/FojPegMhC WsgNy5WsR+jLUduclZDGf4qXxo9Vs1qXeP4qYZOa1rtqiBfFaQsxs4+XyFHdaB8N HzviKd8NSeCn+ZfUTKYlErUAL+qtLaQQTqVvBVnwR9yT74izZ48f0mX8zHYMFJIk mokioFqzl2ZVF98JBLSy6sNTZfO+eg98g3uDVRwq9JyvsWp1OJ94BvoXFZX7ETDM Z53Hp5s3YUNRptlIvzre/foKg4MZB8BNUsEUdgaGOeoXho7jDA== -END CERTIFICATE- It's seemingly self-signed, but then again -- not. When I call openssl: $ openssl verify -CApath /dev/null -CAfile weird.crt weird.crt weird.crt: /CN=WMSvc-WIN-EEBHLC81GJ8 error 20 at 0 depth lookup:unable to get local issuer certificate Interestingly the lookup fails at depth 0 (!). If a parent certificate were missing, I'd expect a lookup fail at depth 1. When I create a self-signed certificate: $ openssl req -new -x509 -nodes -out foobar.crt And check it then: $ openssl verify -CApath /dev/null -CAfile foobar.crt foobar.crt foobar.crt: OK I'm puzzled and before jumping to conclusions wanted to ask you first what you think of that. Best regards, Johannes __ 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] ECDSA sign/verify input data size
Bonjour, Which part of the examples did you mimic? 32 bytes is the length of a SHA256, it's also the max message length of a 256bits ECDSA key. Whence, I assume you're doing straight ECDSA_do_sign() without hashing and padding the message. -- Erwann ABALEA - paléogallicisme: style vieille France Le 06/08/2012 13:11, Mohammad Khodaei a écrit : Hello, I have used ECDSA APIs to sign and verify some data. The sample example I have used to do so is like this: http://old.nabble.com/Bug-in-ECDSA_do_sign--td1071562.html Now, the problem is that it seems there is some kind of limitations on the input data size. Whenever I want to verify the signature on a string, it calculates the signature verification only on the first 32 characters and it skips the rest of the string. It is a bit strange for me since I feed the function with correct length. Any idea where is my mistakes? Thanks a lot __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] ECDSA sign/verify input data size
Use the EVP_* interface for high-level functions. Use ECDSA_do_sign() or other low-level functions if you're absolutely sure about what you're doing. -- Erwann ABALEA Le 06/08/2012 14:31, Mohammad khodaei a écrit : Yes, it's correct. Now I try to feed the ECDSA_do_sign with the output buffer of SHA256. Based on my security knowledge, I thought that the signing algorithms perform hashing internally, while in this case it is not true. Thanks for the response. *From:* Erwann Abalea erwann.aba...@keynectis.com *To:* openssl-users@openssl.org *Cc:* Mohammad Khodaei m_khod...@yahoo.com *Sent:* Monday, August 6, 2012 2:14 PM *Subject:* Re: [openssl-users] ECDSA sign/verify input data size Bonjour, Which part of the examples did you mimic? 32 bytes is the length of a SHA256, it's also the max message length of a 256bits ECDSA key. Whence, I assume you're doing straight ECDSA_do_sign() without hashing and padding the message. -- Erwann ABALEA - paléogallicisme: style vieille France Le 06/08/2012 13:11, Mohammad Khodaei a écrit : Hello, I have used ECDSA APIs to sign and verify some data. The sample example I have used to do so is like this: http://old.nabble.com/Bug-in-ECDSA_do_sign--td1071562.html Now, the problem is that it seems there is some kind of limitations on the input data size. Whenever I want to verify the signature on a string, it calculates the signature verification only on the first 32 characters and it skips the rest of the string. It is a bit strange for me since I feed the function with correct length. Any idea where is my mistakes? Thanks a lot __ 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] Re: create certificate request programmatically using OpenSSL API
GOST is not a block cipher, it's the acronym for GOsudarstvennyi
STandard, which means State Standard. It's not dedicated to cryptography.
Speaking of GOST standard is redundant, but clearer for non russian
locutors.
There's a block cipher (poorly) defined as a GOST standard, referenced
GOST 28147-89. Attempts to be adopted as an ISO standard have failed.
The S-Box to use is not defined in the standard, whence 2 compliant
implementations can be non interoperable.
There's also a hash algorithm defined as a GOST standard, referenced
GOST R 34.11-94 or GOST 34.311-95, using GOST 28147-89 inside. GOST
R 34.11-94 in itself is also useless because of the lack of S-Box
standard. The RFC 4357 defines 2 S-Boxes.
And finally there's a digital signature defined as a GOST standard,
referenced GOST R 34.10-94 and superseded by GOST R 34.10-2001
(RFC5832), consider it similar to ECDSA. It uses GOST R 34.11-94 to
hash data (just as {EC}DSA uses SHA{1,2*}).
--
Erwann ABALEA
Le 28/07/2012 21:31, Jeffrey Walton a écrit :
On Fri, Jul 27, 2012 at 9:00 AM, Abyss Lingvo xidex...@yahoo.com wrote:
Hi all!
The last problem is how to create GOST key pair for certificate.
It is clear how to create RSA keys.
Sample is here : http://www.openssl.org/docs/crypto/EVP_PKEY_keygen.html
#include openssl/evp.h
#include openssl/rsa.h
EVP_PKEY_CTX *ctx;
EVP_PKEY *pkey = NULL;
ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
if (!ctx)
/* Error occurred */
if (EVP_PKEY_keygen_init(ctx) = 0)
/* Error */
if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048) = 0)
/* Error */
/* Generate key */
if (EVP_PKEY_keygen(ctx, pkey) = 0)
/* Error */
Unfortunately there is no EVP_PKEY_GOST constant and I can't create EVP_PKEY
containing GOST key pair.
Does anybody know how to create GOST key pair?
GOST is a block cipher. It uses a symmetric key, not public/private keys.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] X.509 certificate subject format
Le 02/07/2012 10:34, Johannes Bauer a écrit : I have a rather simple question regarding X.509 subjects that is not entirely clear to me and for which I cannot find the appropriate reference (pointers greatly appreciated). The trouble starts when trying to compare two subjects of *different* certificates for equality and becomes worse when certain fields are appearing more than once. To clarify, by equal I mean 'should behave in exactly the same way by all well-behaved implementations. Let's start easy. Consider the following subjects: subject1= /C=SE/O=FooBar/OU=BarFoo/CN=moo.koo.com subject2= /C=SE/OU=BarFoo/CN=moo.koo.com/O=FooBar Are these to be considered equal or not? Not equal. I.e.: Does the order of elements matter? Does the order matter when fields are duplicate, i.e. are: The order of elements in a SEQUENCE matters. The order of elements in a SET doesn't matter (read X.690 to get DER rules). Comparison rules for AttributeAndValue elements follow X.520 recommendation (you have to canonicalize them before comparison). subject1= /CN=foo/CN=bar subject2= /CN=bar/CN=foo equal? Not equal. If they are not equal, does the first one have a special meaning? For example, assume a webserver with a duplicate common name field. Are both names valid as the server name then? I.e. could I access a webserver with the certificate subject as stated above by DNS foo *and* bar or only by one of them? This is not specified by X.509. Browsers tend to accept such a certificate for an accessed FQDN equal to either foo or bar. But you SHOULD place at most the first FQDN in a CN element in the subject, and other FQDN values in the subjectAlternativeName extension. One reason to ask for equality is that there maybe is a certificate X: issuerX = /O=myCA/OU=greatCA/CN=not subjectX= /CN=foo/CN=bar and it has a valid signature by a CA with the following subject: issuerX = /OU=greatCA/O=myCA/CN=not Is the certificate signature then valid? The signature may be cryptographically valid, but the names don't match, so /OU=greatCA/O=myCA/CN=not is not the issuer of /CN=foo/CN=bar (at least not in what you described, /CN=foo/CN=bar may have another certificate). -- Erwann ABALEA - Pas de panique, ça sera pire. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Padding used by the ca command
Bonjour, Le 02/07/2012 16:05, Mathias Tausig a écrit : Which padding method does openssl use, when I sign a certificate with the 'ca' command (using an RSA key)? RSA PKCS#1v1.5 Is there a way to change it? I don't think so. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Padding used by the ca command
Le 02/07/2012 19:38, Dr. Stephen Henson a écrit : On Mon, Jul 02, 2012, Erwann Abalea wrote: Le 02/07/2012 16:05, Mathias Tausig a écrit : Is there a way to change it? I don't think so. In openssl 1.0.1 and later you can use the -sigopt to change the signature format used. It currently supports PKCS#1 v1.5 and PSS. Thanks for the info. I kept the habit of looking in the source code because the help message isn't accurate, but the source I had here was a 1.0.0e. And -sigopt isn't mentioned in the help message ;) -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Bound check on RSA public exponent
The only limit check that I know is performed is if the modulus is strictly larger than OPENSSL_RSA_SMALL_MODULUS_BITS bits (3072 by default), then the public exponent must be less then or equal to OPENSSL_RSA_MAX_PUBEXP_BITS bits (64 by default). You can then have a 3072bits RSA key with a public exponent of any size. Or a 3073bits RSA key with a public exponent limited to 64bits. Other than for performance, I don't see any reason to limit the size of the public exponent. -- Erwann ABALEA Le 21/06/2012 16:41, Sukalp Bhople a écrit : Hello guys, I was looking into the (RSA) certificate verification in Openssl. I was wondering if Opensssl checks the size of the public exponent. Or what is the max public exponent accepted by server? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Bound check on RSA public exponent
Le 21/06/2012 18:18, Sukalp Bhople a écrit : Thank you very much for the helpful response, I searched for the terms you used in your reply and I found them in one of the function. This function is /static int RSA_eay_public_encrypt(int flen, const unsigned char *from,/ /unsigned char *to, RSA *rsa, int padding)/ / / You'll also find it in its decrypt counterpart. I was wondering, if there is any check on e while verifying certificate chains? (For instance, client certificate verification at server side) Why would you want a specific check on e? The check is done on the entire signature, with the entire key. Why e? For example, if the certificate presented by client has very large public exponent then what happen? How this e is stored? There should be some limit (data type BIGNUM) on it? Is this right? In a certificate, the element named subjectPublicKeyInfo is a SEQUENCE composed of 2 items, an algorithm identifier (also a SEQUENCE containing an OID and some parameters) and the subjectPublicKey. The latter is enclosed in a BITSTRING, and if it's an RSA key, it really contains a PKCS#1 encoded public key: a SEQUENCE containing 2 INTEGERS, modulus and public exponent. You can have any sized INTEGERS in here, and OpenSSL will parse them correctly. If the certificate has a very large public exponent, and a verification is performed, and the described limits are not overridden, there's no problem to expect. If you comment the limits in your own compiled library, there will still be no problem. You can get into a situation where a public RSA operation takes more time than a private one, if e is sufficiently large. But that's all. On Thu, Jun 21, 2012 at 5:14 PM, Erwann Abalea erwann.aba...@keynectis.com mailto:erwann.aba...@keynectis.com wrote: The only limit check that I know is performed is if the modulus is strictly larger than OPENSSL_RSA_SMALL_MODULUS_BITS bits (3072 by default), then the public exponent must be less then or equal to OPENSSL_RSA_MAX_PUBEXP_BITS bits (64 by default). You can then have a 3072bits RSA key with a public exponent of any size. Or a 3073bits RSA key with a public exponent limited to 64bits. Other than for performance, I don't see any reason to limit the size of the public exponent. Le 21/06/2012 16:41, Sukalp Bhople a écrit : Hello guys, I was looking into the (RSA) certificate verification in Openssl. I was wondering if Opensssl checks the size of the public exponent. Or what is the max public exponent accepted by server? -- Erwann ABALEA - ovopostégallinadoxie: doctrine qui soutient que la poule est apparue avant l'oeuf
Re: [openssl-users] Question regarding renegotiation in openssl-1.0.1
Why should it be different? -- Erwann ABALEA - gérontopropulsion prurigineuse: abus d'excès caractérisé par trop d'exagération (se fait quand on pousse mémé dans les orties) Le 13/06/2012 13:30, ankur dwivedi a écrit : Hi, I am observing that after doing a renegotiation, the new cipher is same as what was used while initial handshake. Is this a normal behavior ? -- Thanks Ankur Dwivedi
Re: [openssl-dev] RE: Clarification regarding extension supported in OpenSSL certificates.
Yes to everything. As your question is not about the development of OpenSSL, but instead about its use, it should have been better in the openssl-users mailing list. Le 28/05/2012 15:43, Manas Ranjan Lenka a écrit : Hi, In addition to the below queries we have one more query in our mind. Please help us in answering to all those. 1.Does OpenSSL support SHA-256 hash Algorithm before signing certificate? Regards ManasL *From:*Manas Ranjan Lenka *Sent:* 28 May 2012 18:41 *To:* 'openssl-...@openssl.org' *Subject:* Clarification regarding extension supported in OpenSSL certificates. Hi, We are using openSSL command line tool for generating version 3 CA certificates as well IKE initiator/Responder certificates. We have the following doubts in our mind, Could you please clarify the same. 1.Does openSSL support version 3 certificate which is compliant to RFC 5280? 2.Does openSSL supports the following (Mandatory/Optional) extensions for CA Certificate as per section 6.1.4 of 3GPP spec TS 33.310. Mandatory: 1.key usage: keyCertSign and cRLSign. 2.basic constraints: CA=True, path length 0. Optional: 3.authority key identifier. 4.subject key identifier. Regards Manas Lenka -- Erwann ABALEA - If it walks like a duck, and quacks like a duck, then it just may be a duck. - Reuther
Re: [openssl-users] How does openSSL handle the pathlen constraint?
Le 22/05/2012 10:57, Eisenacher, Patrick a écrit : -Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Taken from X.509, 2008/11 edition. But IIRC, the algorithm is the same since the 2000 edition, at least. - 10.5 Certificate processing Each certificate is then processed in turn, starting with the certificate signed using the input trusted public key. The last certificate is considered to be the end certificate; any other certificates are considered to be intermediate certificates. - Note that the first certificate taken into consideration is signed by the trust anchor, and not the trust anchor itself. - 10.5.1 Basic certificate checks The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored. a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked. b) For an intermediate version 3 certificate, check that basicConstraints is present and that the cA component in the basicConstraints extension is TRUE. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint (ignoring intermediate self-issued certificates) [...other basic steps...] - The same logic applies for other constraints extensions. Basically, from the trust anchor, you only take the public key, name, and validity dates. No extension at all. That's because a trust anchor doesn't need to be a certificate at all. -- Erwann ABALEA - OF C'est quoi godwin ? un jeu ? une personne ? Une sorte de station-service : on accumule les points et on peut gagnerune gamelle. -+- PE in Guide du Neuneu d'Usenet - Le point sur les godwins -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How does openSSL handle the pathlen constraint?
Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. -- Erwann ABALEA - Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes idées doivent être reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Possible bug in openssl?
Le 10/05/2012 11:39, Andreas Bießmann a écrit : [...] (one of the errournous boxes) ---8--- abiessmann@azuregos % date Do 10. Mai 11:02:50 CEST 2012 abiessmann@azuregos % openssl version OpenSSL 1.0.1b 26 Apr 2012 abiessmann@azuregos % openssl s_client -connect banking.postbank.de:443 CONNECTED(0003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 320 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- ---8--- (the same for all boxes which use 1.0+ release) My questions: * can anyone confirm this behaviour (it seems other hosts are working with openssl 1.0+, but not the banking.postbank.de)? * can anyone give me a hint how to track this down? I happen to get the same behaviour behind our firewall when ECDHE-whatever is negociated as the ciphersuite. The FW drops the connection, resulting in this errno=104 error. Try to limit the set of ciphersuites in your client. -- Erwann ABALEA - Lu sur alt.france : Peut-on installer Win 95 par dessus win 95 tout en gardant les differents données des logiciels fonctionnant auparavant sur wwin 95 ? -+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Possible bug in openssl?
Le 10/05/2012 13:41, Andreas Bießmann a écrit : On Thu, May 10, 2012 at 12:38:00PM +0200, Erwann Abalea wrote: Le 10/05/2012 11:39, Andreas Bießmann a écrit : My questions: * can anyone confirm this behaviour (it seems other hosts are working with openssl 1.0+, but not the banking.postbank.de)? * can anyone give me a hint how to track this down? I happen to get the same behaviour behind our firewall when ECDHE-whatever is negociated as the ciphersuite. The FW drops the connection, resulting in this errno=104 error. Try to limit the set of ciphersuites in your client. Ok so 'openssl s_client -connect banking.postbank.de:443 -cipher AES256-SHA' works with 1.0.1b. Thanks so far. After more tests on this host, it appears it suffers from the 0xff limit ClientHello bug. Try adding a large SNI extension to make this message bigger, by adding the -servername xx argument to your command line, with a sufficiently large xx string. It will stop working. With this only cipher accepted, the xx has to be at least 192 bytes long to cause the server to fail. Your firewall is probably OK, your client is OK, the server is faulty. But it is nasty to limit cipher by host. So I could exclude all these ECDHE- stuff if these really causing the error. But I wonder if there is another solution. I see this behaviour with all tools using openssl 1.0.1. I found it first with python on my mac and asked myself why it works from time to time (python packaged by fink uses openssl-1.0.1, Apple's version uses openssl-0.9.8 ;). However that could be fixed by working around in my scripts but wget fails also and curl does, ... So I ask myself 'could there be a solution inside the library?'. The problem lies in the server, it's difficult to change the client's behaviour to correctly adapt to buggy servers. -- Erwann ABALEA - Quelqu'un peut me dire comment on fait pour creer un nouveaux groupe Usenet? A qui faut-il s'adresse? Cela coute il de quoi? -+- Moe in GNU - De quoi qu'est ce que ca coute-t-il combien ? -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RES: Random number generator
It replies '42' everytime. And that's a good answer. Le 05/04/2012 13:35, Leonardo a écrit : I'd like to add some question about this. What kind of RNG is implemented? Linear Congruential generator? Is it another more sophisticated? Thanks Leonardo *De:*owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *Em nome de *Prashanth kumar N *Enviada em:* quinta-feira, 5 de abril de 2012 01:07 *Para:* openssl-users@openssl.org *Assunto:* Re: Random number generator You can use the below API's RAND_bytes() RAND_pseudo_bytes() On Thu, Apr 5, 2012 at 12:33 AM, Jeremy Farrell jeremy.farr...@oracle.com mailto:jeremy.farr...@oracle.com wrote: http://lmgtfy.com/?q=openssl+random+number From: Alex Chen [mailto:alex_c...@filemaker.com mailto:alex_c...@filemaker.com] There is a 'rand' command in the openssl command line tool to generate 'pseudo' random number generator. But I cannot find the API from either the 'ssl' or 'crypto' man pages. Can someone point me to the API page if it is available? Is this RNG implementation different in the regular distribution and the FIPS Object module? __ 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 -- Erwann ABALEA - Ca fait déjà plusieurs semaines que jessaie de correspondre par l intermédiaire dun groupe de discussion. Ca ne fait que deux jour que je suis parvenu à expédier un message -+- GM in GNU : Patience et longueur de temps.. -+-
Re: [openssl-users] Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
Le 04/04/2012 05:22, Curt Sampson a écrit : [...] In fact, if one can be encoded in a shorter form than the other, it MUST be encoded in that shorter format. This is because certificates use DER, not BER, and DER says that. As pointed by Peter Sylvester, BER doesn't allow useless leading 00 octets either in the content. The content MUST be serialized with the lowest possible number of octets. The difference between BER and DER for integers encoding is on the length encoding (02 81 01 01 is valid BER, not valid DER; 02 01 00 01 is neither valid BER nor DER). -- Erwann ABALEA - N'ouvrez aucun message ayant pour objet RETURNED OR ENABLE TO DELIVER. ce virus se greffe tout seul à tout les composants de votre ordinateur et les détruit. Ce message vous est envoyé par l'équipe du QUICK DRIVE -+-AL in: Guide du Neuneu Usenet - Le virus Mad Cow frappe encore -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
Ok. Now switching to openssl-users mailing list, sorry for RT moderators and OpenSSL developers. Tamir, We are not speaking about different things. You either fail to understand, or fail to explain, and you're constantly using wrong terms. For example, what you provided is *not* a certificate, it is an RSA private key. That's absolutely not the same thing. In this private key, exponent1, exponent2 and coefficient are encoded with different lengths because they *are* of different lengths. Is there anything somewhere preventing these numbers to be of different lengths? In other terms, is there any formal document stating that these elements MUST be of equal lengths? I haven't paid for the ISO8825 document, but I have its free ITU-T version, X.690 (it's the same text). Below is paragraph 8.3 if this standard: - 8.3 Encoding of an integer value 8.3.1 The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets. 8.3.3 The contents octets shall be a two's complement binary number equal to the integer value, and consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets. NOTE – The value of a two's complement binary number is derived by numbering the bits in the contents octets, starting with bit 1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2N, where N is its position in the above numbering sequence. The value of the two's complement binary number is obtained by summing the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then reducing this value by the numerical value assigned to bit 8 of the first octet if that bit is set to one. - Where in this text is said that a sequence of integers must be encoded with the same length? Could you take your provided example of a badly encoded key and provide a representation of what would be a good encoding, clearly? My guess is that you would like to have an additional leading 00 octet in exponent2' serialization. That would give the following encoding: 02 41 00 00 80 5B 5F BB 4F 28 E4 EA 7A 19 52 55 37 81 14 AA B3 D3 34 51 A5 A8 91 28 82 AE 58 3F 80 36 27 48 20 88 E1 08 C0 A8 46 16 64 86 FF 9E CD 5D 9E 48 42 BF 25 F8 47 85 91 E4 A2 13 71 0A C1 C7 A9 Am I right? If my guess is correct, then you need to re-read the 8.3 paragraph again and again. Rule 8.3.2 states that bits of the first octet and bit 8 of the second octet (of the content octets) can not be all zero. This example doesn't follow the rule. Your supposedly-bad provided example does. Le 03/04/2012 11:34, Tamir Khason via RT a écrit : It seemed that we are speaking about different things. In certificate i pasted, integers used for exponent1, exponent2 and coefficient encoded with different lengths. In chapter 8.3 of ISO 8825 there is clear statement of how integer values should be encoded. All need is to take those numbers from bad certificate i pasted and encode it by using different 8825 implementations to see leading zeros appear. When openssl encode those number leading zeros are missing. This is what i claim as a bug. On Tue, Apr 3, 2012 at 11:58 AM, Erwann Abalea via RTr...@openssl.org wrote: Le 03/04/2012 09:38, Tamir Khason via RT a écrit : Please see decrypted private key http://pastebin.com/DzYLnHZT Thanks. You didn't provide information on where you think the error is, precisely. I'll base my answer on your previous posts. You started to say that the coefficients should be of the same length. By coefficient, you mean the CRT parameters (exponent1, exponent2, coefficient). You didn't provide an authority source to back up this assertion. In fact, it's false, and has been explained why. There's no optimization trick, no particular decision, some parameters can be smaller than others, that happens, and it's not wrong. You then talked about end-of-content octets. There's no such octet in the provided example. And there's no end-of-content octet possible in the DER representation of an object. End-of-content octets are found with indefinite length objects, when you don't know in advance the size of the object you're encoding, but can tell when it ends; think of it as streaming, for example. This is allowed with BER only, not DER. It was explained to you how an integer is serialized in DER, in order to be sure that it's the smallest representation of the integer, without any
Re: [openssl-users] Support for certificates other than the X509 standard Reg.
Bonjour, Out of my head, there's ISO7816-6 certificates, used at least in eID projects (EAC passports). One can also mention PGP/GPG (which can now include X.509), with a marginal use (in corporate/business world). OpenSSL has a great support for X.509, of course, but since it also includes complete ASN.1 and crypto API, you can easily work with ISO7816-6 certificates. I haven't used PGP/GPG since a few years so I don't really know if there's an ASN.1 description, but the crypto is the same, for sure. Le 31/01/2012 17:07, Ashok C a écrit : I understand that X509 is the preferred ITU-T standard for PKI. But what would be the other certificate standards which are available and those which a PKI solution needs to support? First question would be whether there are any certificates which do not belong to the X509 standard? Also, what all standards of certificates does the openSSL implementation support? -- Erwann ABALEA - Depuis ce matin, j'ai une IP en 213.@@@.@@@ et des plumes. C'est devenu apparement une IP statique. Mon contrat me donne droit à une IP dynamique.. -+- TW inhttp://neuneu.mine.nu : Neuneu se fixe -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] deff hellman
Bonsoir, This is an english spoken mailing list, so I'll reply in english. With Diffie-Hellman, g (the generator) is public, and can thus be shared by all the actors (nodes, in your study). Each actor's private key (a or b in your example) is used only once and discarded at the end of the session, or you lose the forward secrecy ability. In your study, you could either build a session key with each individual node participating in the session, or all the participating nodes could generate a common session key: - Alice, Bob, and Carol all choose their private keys (a, b, c) - Alice sends g^a to Bob - Bob sends (g^a)^b to Carol - Carol computes ((g^a)^b)^c and keeps it secret - Bob sends g^b to Carol - Carol sends (g^b)^c to Alice - Alice computes ((g^b)^c)^a and keeps it secret - Carol sends g^c to Alice - Alice sends (g^c)^a to Bob - Bob computes ((g^c)^a)^b and keeps it secret - Alice, Bob, and Carol share the same secret: g^abc If you carefully choose p (size and factors of p-1), then you don't have to worry about finding a given g^a mod p. Look for General Number Field Sieve to get numbers, this is the most efficient algorithm so far, with large enough p. In your presented study, authentication is left aside. That's good for a school study, but not for real life work. Le 19/01/2012 17:01, BENAMAR Lydia a écrit : Bonsoir, dans le cadre de notre projet de fin d'étude, nous sommes amenées à utiliser la technique de Deff Hellman afin d'initier une session entre la source des paquets et tous les noeuds du chemins. si vous permettez on a quelques questions à vous poser. est ce que la source peut échanger le même g et a avec tous les noeuds du chemin? quel est le temps nécessaire pour un attaquant qui écoute les valeur g^a et g^b pour connaitre g^ab? quel algorithme est le plus approprié en terme d'efficacité et de consommation des ressources? en attente de toute suggestion, acceptez nos salutations. -- Erwann ABALEA - caïssaphique: se dit d'une lesbienne qui joue aux échecs. (Caïssa est la déesse des échecs) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 15:07, Jakob Bohm a écrit : I think we may have a bug here, anyone from the core team wish to comment on this. The apparent bug: When enforcing the match policy for a DN part, openssl reports an error if the CSR has used a different string type for the field, but the correct value (The naively expected behavior is to realize the strings are identical and use the configured encoding for the resulting cert). Do you expect the openssl ca tool to apply the complete X.520 comparison rules before checking the policy? 3. Validating a certificate whose issuing CA certificate specifies path constraints where the issued certificate satisfies the path constraint except for the exact choice of string type. NameConstraints is a set of constraints imposed on the semantic value of the name elements, not on their encoding (string type, double-spacing, case differences, etc). Technical note: All the defined string types have a well defined mapping to and from 32 bit Unicode code points, with the following one-way limitations: BMPStrings can only represent U+ to U+10 (using UTF-16) UTF8Strings can only represent U+ to U+7FFF (allowing the possibility that some codepoints above U+10 may be assigned in the future, contrary to current policy). (OpenSSL may or may not accept the CESU-8 and Java Modified UTF-8 encoding variants and may or may not normalize those to real UTF-8 before further processing). PrintableString can only represent a specific small set of Unicode code points T61String can only represent a different specific small set. T.61 has no well defined bidirectional mapping with UTF8. That said, T.61 was withdrawn before 1993 (IIRC) and shouldn't be used. -- Erwann ABALEA - yétiscopique: relatif à certaines vapeurs des sommets himalayens __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
man req Then look for the -utf8 argument. I took your example below, added -utf8 argument, and it worked. You can display the content with openssl req -text -noout -in blabla.pem -nameopt multiline,utf8,-esc_msb Le 16/12/2011 16:33, Lou Picciano a écrit : openssl req -new -sha1 -nodes \ -nameopt multiline,show_type \ -keyout private/THORSTROM.key \ -out csrs/THORSTROM.csr \ -subj /O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom -- Erwann ABALEA - vésicosufflochromateur: supérieur à 0,5 gramme
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 17:57, Mick a écrit : On Friday 16 Dec 2011 16:23:52 you wrote: man req Then look for the -utf8 argument. I took your example below, added -utf8 argument, and it worked. You can display the content with openssl req -text -noout -in blabla.pem -nameopt multiline,utf8,-esc_msb Would using -utf8 resolve the original OP problem? To create the request/certificate, yes. This is what I do to embed accented characters in UTF8. Typing openssl req -utf8 -new -nodes -newkey rsa:512 -keyout THORSTROM.key -out THORSTROM.csr -subj /O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom on an UTF8 capable terminal, with a string_mask = utf8only in the right openssl.cnf file, gives me a certificate request correctly encoded in UTF8 with the wanted characters in the DN. -- Erwann ABALEA - minilactopotage: intense satisfaction
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 16:29, Jakob Bohm a écrit : On 12/16/2011 3:22 PM, Erwann Abalea wrote: Le 16/12/2011 15:07, Jakob Bohm a écrit : I think we may have a bug here, anyone from the core team wish to comment on this. The apparent bug: When enforcing the match policy for a DN part, openssl reports an error if the CSR has used a different string type for the field, but the correct value (The naively expected behavior is to realize the strings are identical and use the configured encoding for the resulting cert). Do you expect the openssl ca tool to apply the complete X.520 comparison rules before checking the policy? Not unless there are OpenSSL functions to do the work. Otherwise I just expect it to apply the character set conversions it uses for its other operations (such as reading the config file/displaying DNs). Fair. I personally use the openssl command line tools to have a quick CA, not a full-featured one. The API is complete and allows to code this. But you're right, it would be fair to have consistent behaviour. 3. Validating a certificate whose issuing CA certificate specifies path constraints where the issued certificate satisfies the path constraint except for the exact choice of string type. NameConstraints is a set of constraints imposed on the semantic value of the name elements, not on their encoding (string type, double-spacing, case differences, etc). The question was how the OpenSSL code (library and command line) handle the scenario, your answer seems to indicate that it is indeed supposed to compare the semantic character sequence, not the encoding. That's what X.509 and X.520 impose. An algorithm is described in X.520 for name comparisons. T.61 has no well defined bidirectional mapping with UTF8. That said, T.61 was withdrawn before 1993 (IIRC) and shouldn't be used. According to RFC1345, T.61 has a well defined mapping to named characters also found in UNICODE. Some of those are encoded as two bytes in T.61 (using a modifier+base char scheme), the rest as one byte. That is what I mean by a bidirectional mapping to a small (sub)set of UNICODE, meaning that most UNICODE code points cannot be mapped to T.61, but the rest have a bidirectional mapping. I'm not finished with the reading of T.61 (1988 edition), but here's what I found: - 0xA6 is the '#' character, 0xA8 is the '¤' character (generic currency), but those characters can also be obtained with 0x23 and 0x24, respectively (Figure 2, note 4). Later in the same document, 0x23 and 0x24 are declared as not used. This is both ambiguous and not bidirectional. - 0x7F and 0xFF are not defined, and are not defined as not used. - 0xC9 was the umlaut diacritical mark in the 1980 edition, which is still tolerated in the 1988 edition, but the tables don't clearly define 0xC9 (and again, don't define it as not used). 0xC8 is declared as diaresis or umlaut mark. As I don't have the 1980 edition, I don't know if it was already the case. - nothing is said if a diacritical mark is encoded without a base character. These are ambiguities. Annexes define control sequences (longer that 2 bytes), graphical characters, configurable character sets, presentation functions (selection of page format, character sizes and attributes (bold/italic/underline), line settings (vertical and horizontal spacing)). I doubt everything can be mapped to UTF8. Constructing a mapping table from the data in RFC1345 or other sources is left as an exercise for the reader (cheat hint: Maybe IBM included such a table in ICU or unicode.org included one in its data files). I think only a subset of T.61 is taken into consideration. But I haven't looked at the hinted files. -- Erwann ABALEA - D'abord, on est sur le web, pas sur ce usenet dont on nous rabbache les oreilles et qui n'est qu'une abstraction. -+- JP in http://neuneu.ctw.cc - Neuneu en abstract mode -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 18:27, Jakob Bohm a écrit : On 12/16/2011 6:14 PM, Erwann Abalea wrote: Le 16/12/2011 17:57, Mick a écrit : On Friday 16 Dec 2011 16:23:52 you wrote: man req Then look for the -utf8 argument. I took your example below, added -utf8 argument, and it worked. You can display the content with openssl req -text -noout -in blabla.pem -nameopt multiline,utf8,-esc_msb Would using -utf8 resolve the original OP problem? To create the request/certificate, yes. This is what I do to embed accented characters in UTF8. Typing openssl req -utf8 -new -nodes -newkey rsa:512 -keyout THORSTROM.key -out THORSTROM.csr -subj /O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom on an UTF8 capable terminal, with a string_mask = utf8only in the right openssl.cnf file, gives me a certificate request correctly encoded in UTF8 with the wanted characters in the DN. Sorry, but OP's problem seems to be that the CSR was created by some software embedded in a router, Sorry, I replied to the problem described by Lou Picciano, and forgot that Mick was the OP. My fault. -- Erwann ABALEA - Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour fonctionner,à force,en France de refuser tout rapport sain avec l'argent,l'on riqsque de tuer ce nouvel outil. -+- AA in: Guide du Neuneu d'Usenet - Le netétiquette du riche -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 18:45, Mick a écrit : [...] Indeed, the message was rather esoteric and it did not offer a way out - e.g. it could have advised to change match to supplied in openssl.cnf, or to ensure that the encoding between the CSR and ca is the same. I think what confused me is that by uploading the cacert to the router I would expect the router to respect the cacert's encodings. It evidently did not. It doesn't need to :) Since I cannot change the router firmware, what should I change the 'string_mask = ' on the PC to agree with the router? My understanding is that string_mask is used when producing an object (request or certificate), not when checking its content with the policy match directives. You could either regenerate your CA with string_mask set to default (which means: first try PrintableString, then T61String, then BMPString). Your router uses PrintableString for pretty much anything except commonName, which is encoded in T61String. That could work. Or you could keep your CA certificate as is, change the policy directives (from match to supplied), and manually check the requests. Or code something with openssl req -text -nameopt multiline,utf8,-esc_msb ..., extracting the RDNs, comparing with what is set in the CA certificate (the -nameopt ... argument will convert everything into UTF8, easing the comparison), whence performing your own validation. -- Erwann ABALEA - Désolé. Ta gueule. -+- LC in : Guide du Neuneu Usenet - Neuneu exaspère le dino -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 19:07, Jakob Bohm a écrit : On 12/16/2011 6:47 PM, Erwann Abalea wrote: Le 16/12/2011 16:29, Jakob Bohm a écrit : On 12/16/2011 3:22 PM, Erwann Abalea wrote: NameConstraints is a set of constraints imposed on the semantic value of the name elements, not on their encoding (string type, double-spacing, case differences, etc). The question was how the OpenSSL code (library and command line) handle the scenario, your answer seems to indicate that it is indeed supposed to compare the semantic character sequence, not the encoding. That's what X.509 and X.520 impose. An algorithm is described in X.520 for name comparisons. I understand, but does OpenSSL implement that? In the API, yes. At least in 1.0.0 branch, which passes the NIST PKITS suite. I'm not finished with the reading of T.61 (1988 edition), but here's what I found: - 0xA6 is the '#' character, 0xA8 is the '¤' character (generic currency), but those characters can also be obtained with 0x23 and 0x24, respectively (Figure 2, note 4). Later in the same document, 0x23 and 0x24 are declared as not used. This is both ambiguous and not bidirectional. As you quote it (I don't have a copy), this sounds like using 0x23 and 0x24 should not be done when encoding, but should be accepted when decoding. Yes, and that also means those characters cannot be obtained with 7-bit T.61, contrary to the table found in RFC1345. In fact, there's no 7-bit T.61 set, so I don't really know how RFC1345 should be treated. - 0x7F and 0xFF are not defined, and are not defined as not used. RFC1345 seems to indicate that 0x7F maps to U+007F DEL This mapping (0x7F - DEL) is only presented in Annex E, discussing the greek primary character set. But the Table 2, which exhaustively lists the codes, avoids 0x7F (07/15, really). Some PKI toolkits use T.61 to encode ISO8859-1 characters, and ISO8859-1 defines 0x7F as DEL. Annexes define control sequences (longer that 2 bytes), graphical characters, configurable character sets, presentation functions (selection of page format, character sizes and attributes (bold/italic/underline), line settings (vertical and horizontal spacing)). I doubt everything can be mapped to UTF8. Most of those would be inapplicable to the encoding of X.500 strings, configurable character sets sounds like an ISO-2022 like mechanism useful for encoding an even larger subset of UNICODE, as do graphical characters. However none of those features were mentioned in the still available secondary references I looked at (RFC1345 and Wikipedia), so they are unlikely to be accepted nor emitted by any current implementations of T.61. Sure. But those are valid T.61 sequences anyway. As you said, RFC1345 lists historic character sets, and T.61 is one of them (if predates Unicode). T.61 was ambiguous, was defined for a now obsolete system (Teletex), was more than a simple character set (you could redefine graphical characters, and specify formatting), and is now withdrawn since nearly 2 decades. It's time to avoid it :) -- Erwann ABALEA - préhibernoluthidolichospasmes: sanglots longs des violons de l'automne, phénomène météomusical aux propriétés homéoanémicardiomutilatoires, décrit pour la première fois par Verlaine en 1866 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Special character in CA name
Do you have an UTF8 capable terminal? Can you send the certificate you're testing? Le 15/12/2011 09:17, gkout a écrit : No joy... openssl x509 -text -noout -in blablabla.pem -nameopt -esc_msb outputs : ESPA%D1A -- Erwann ABALEA - ypéritorhinotachytrope: colérique, qui s'énerve rapidement __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Special character in CA name
Have you tried this: openssl x509 -text -noout -in blablabla.pem -nameopt -esc_msb Le 14/12/2011 19:16, Vladimir Puz a e'crit : I have the same problem, but with KOI8-RU certificates. It will be great if someone can help. *On Wed, 14 Dec 2011 16:19:41 + (UTC), Lou Picciano wrote* as I understand it, using the utf8 option should allow any characters you might want. Let us know how you get on; I've had trouble with this, too... Lou Picciano *From: *gkout koutra...@yahoo.com *To: *openssl-users@openssl.org *Sent: *Tuesday, December 13, 2011 5:35:27 PM *Subject: *Special character in CA name Hello again, This time I have an issue with a special character in the CA name which is converted by openssl. ESPA\xC3\x91A which should read [UTF-8?]ESPAц▒A with an [UTF-8?]ц▒. -- Erwann ABALEA - Comme je ne veux pas fournir mon n°CB par Internet (...) je n'ai pas pu tester le syste`me. Mais j'aimerais bien avoir l'avis de quelqu'un qui l'a essaye'. -+- N in : Guide du Neuneu Usenetien - Passez devant je vous suis -+-
Re: [openssl-users] Re: specifying certificate extensions on command line
No. You can generate your conf file based on other elements, if you need something more flexible. Le 07/12/2011 13:06, sandeep kiran p a écrit : Anyone? can I do this without the conf file? Thanks Sandeep On Thu, Dec 1, 2011 at 7:36 PM, sandeep kiran p sandeepkir...@gmail.com mailto:sandeepkir...@gmail.com wrote: Hi, Is there any way to specify the certificate extensions (when using req and ca tools) directly on the command line rather than using the -extensions argument? I am looking for a way where I can avoid using the config file with the req and ca commands. Thanks, Sandeep -- Erwann ABALEA - pyropyge: qui a le feu aux fesses
Revocation with a renewed/rekeyed Root CA
Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) Given CA1g1 and CRLg1 in the CApath, I can validate U2 and U3, and U1 is correctly declared revoked. I now renew CA1, with a rekey. I now have a second generation of the same CA (same name), lets call it CA1g2. CA1g2 issues U4, U5, U6. Given a CApath containing CA1g1, CA1g2, and CRLg1, I can still validate U2 and U3, and check that U1 is revoked. However, I cannot check U4 to U6, OpenSSL complains that it cannot find the CRL (I used strace to check that it reads the CRL xxx.r0, and tries to find another one xxx.r1). If I generate a new CRL with CA1g2 (named CRLg2), and replace CRLg1 with CRLg2 in the CApath, I cannot validate U1 to U3 (same result: cannot find CRL), but I can validate U4 to U6. It seems OpenSSL follows the RFC5280 rule added during the transition from RFC3280 to RFC5280, which says the trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate (6.3.3, f). However, this constraint is only local to RFC5280, it didn't exist before, and does not exist in X.509. Read paragraph 8.1.5 of the 2008 edition of X.509: - If an authority uses the same key to sign certificates and CRLs, a single self-issued certificate of category a) shall be used. If an authority uses a different key to sign CRLs than that used to sign certificates, the authority may choose to issue two self-issued certificates of category a), one for each of the keys. In this situation, certificate users would need access to both self-issued certificates to establish separate trust anchors for certificates and CRLs signed by that authority. - category a) is a self-signed certificate, issued as a convenient way of encoding the public key associated with the private key used to sign the certificate, so that it can be communicated to, and stored as trust anchors by, its certificate using systems. I looked at the test descriptions of the NIST's PKITS, the renewal of the root is not taken into consideration, no help from them. So, while the PKIX IETF point of view is now clearly: you never renew the whole hierarchy, you just create a new one in parallel, which can eventually have the same name, it contradicts X.509 (a CA is a name). Shouldn't OpenSSL give a way to follow X.509 rather that RFC5280? Have I missed a specific option that does just that? -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. -- Erwann ABALEA - j'ai entendu dire qu'une société allait commercialiser des logiciels permettant de ne pas télécharger les pubs et je vous trouvre cela inadmissible. Les sites seront mis tout nu et cela ridiculisera le site. -+- BL in: Guide du Neuneu d'Usenet - A poil, tout le monde a poil -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
Le 17/10/2011 16:09, Jakob Bohm a écrit : On 10/17/2011 3:47 PM, Erwann Abalea wrote: Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. [OT note, please discuss in separate thread] I have seen CAs that declare an additional CRL for potentially revoking the CA itself. Yes, and that was supported by mod_ssl, even for non self-signed CAs, before the switch to OpenSSL CRL mechanism. That's not standard, of course. That CRL is initially empty, but might one day be replaced by one that revokes the (self-)issued CA cert, thus invalidating itself. A recipient of such a suicide CRL has two reasonable options: A) Accept it and revoke its own trust in that CA. B) Declare a logic error thus preventing use of that CA until the compromising entity issues a new empty CRL. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. Just to clarify: Does the renewed CA have the same public/private key but different attributes/expiry or does it have different public/private key and different attributes/expiry? (I understand that they have the same distinguished name). As I said, I renewed and rekeyed it. So that's a new key pair, for the same CA (same name), and of course different validity dates. -- Erwann ABALEA - apyrolacustre: pouvant attendre __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Revocation with a renewed/rekeyed Root CA
I forgot to tell that I did these tests with version 1.0.0e. Le 17/10/2011 14:14, Erwann Abalea a écrit : Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) Given CA1g1 and CRLg1 in the CApath, I can validate U2 and U3, and U1 is correctly declared revoked. I now renew CA1, with a rekey. I now have a second generation of the same CA (same name), lets call it CA1g2. CA1g2 issues U4, U5, U6. Given a CApath containing CA1g1, CA1g2, and CRLg1, I can still validate U2 and U3, and check that U1 is revoked. However, I cannot check U4 to U6, OpenSSL complains that it cannot find the CRL (I used strace to check that it reads the CRL xxx.r0, and tries to find another one xxx.r1). If I generate a new CRL with CA1g2 (named CRLg2), and replace CRLg1 with CRLg2 in the CApath, I cannot validate U1 to U3 (same result: cannot find CRL), but I can validate U4 to U6. It seems OpenSSL follows the RFC5280 rule added during the transition from RFC3280 to RFC5280, which says the trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate (6.3.3, f). However, this constraint is only local to RFC5280, it didn't exist before, and does not exist in X.509. Read paragraph 8.1.5 of the 2008 edition of X.509: - If an authority uses the same key to sign certificates and CRLs, a single self-issued certificate of category a) shall be used. If an authority uses a different key to sign CRLs than that used to sign certificates, the authority may choose to issue two self-issued certificates of category a), one for each of the keys. In this situation, certificate users would need access to both self-issued certificates to establish separate trust anchors for certificates and CRLs signed by that authority. - category a) is a self-signed certificate, issued as a convenient way of encoding the public key associated with the private key used to sign the certificate, so that it can be communicated to, and stored as trust anchors by, its certificate using systems. I looked at the test descriptions of the NIST's PKITS, the renewal of the root is not taken into consideration, no help from them. So, while the PKIX IETF point of view is now clearly: you never renew the whole hierarchy, you just create a new one in parallel, which can eventually have the same name, it contradicts X.509 (a CA is a name). Shouldn't OpenSSL give a way to follow X.509 rather that RFC5280? Have I missed a specific option that does just that? -- Erwann ABALEA - DP http://couic-couic.fr le lien ne marche pas... -+- W in: Guide du Neuneu d'Usenet - Je lui fais couic-couic -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] View OCSP response in CMS
Le 21/09/2011 21:20, Gabriel Marques a écrit : I'm developing a tool for signing digital TV apps, and one of the goals was to embed OCSP responses into the CMS signature file of the application. The idea is that the broadcaster equipment would query the OCSP and update the response with certain frequency, so that the receiver could check the certificate validity without Internet connection. Well, using the BouncyCastle lib I've forcedly embedded the response in the OtherRevocationInfoFormat field of the CMS file, but OpenSSL does not like the way I did it: - openssl cms -cmsout -print -inform der -in /tmp/sig3/META-INF/BR-ecdsaTest.EC Error reading S/MIME message 3076389608:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319: 3076389608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=X509_CRL_INFO 3076389608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:751:Field=crl, Type=X509_CRL 3076389608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:751: 3076389608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:339:Field=d.crl, Type=CMS_RevocationInfoChoice This could be because I'm doing something wrong (probably) or because OpenSSL (1.0e) is alway expecting a CRL set where other kind of revocation info could be present. I couldn't find a clear way to do insert OCSP responses into a CMS structure. The RFCs are the clearer source I could get: RFC 3852 - CMS structure: The latest RFC for CMS is 5652. But the phrasing is the same: - IF ((certificates is present) AND (any certificates with a type of other are present)) OR ((crls is present) AND (any crls with a type of other are present)) THEN version MUST be 5 ELSE [...] - In your examples, you set version to 3. Based on your parsed example, it seems you correctly set the tag ([1]) for the crls element, but you didn't use the good encoding for the other field (of type OtherRevocationInfoFormat, as it also must be tagged ([1]) and be identified by the correct OID (1.3.6.1.5.5.7.16.2). -- Erwann ABALEA - Le neuneu est un con qui débute. C'est une espèce rare mais qui fait beaucoup de bruit. -+- JCD in : Guide du Neuneu d'Usenet -- Bien configurer son neuneu.-+-
Re: [openssl-users] openssl and rfc 5280
Le 22/09/2011 16:10, Roger No-Spam a écrit : Hi, I'm trying to understand if openssl is a good base when implementing a system that is to be compliant with rfc 5280. Are there any limitations or missing parts in openssl? Using OpenSSL, you can implement a system mostly compliant with RFC5280. You will have to enforce some constraints by yourself, for example: - check that the serial number of a certificate is positive and no longer than 20 octets - check the AVA lengths (64 for a CN, O, OU, ...) - check that the basicConstraints extension for a CA is present and critical, with its CA flag set - check that the certification path of a verified certificate and the certification path of the CRL used to check its revocation status meet to the very same trustpoint (key) - ... probably some others The fact is OpenSSL is not pure RFC5280, it's a toolkit you can use for pretty much anything regarding PKI (X.509 and others), crypto, SSL, ... RFC5280 is a profile of X.509, i.e. X.509 with constraints. -- Erwann ABALEA - apaléostéoplasique: qui ne fait pas de vieux os
Re: [openssl-users] View OCSP response in CMS
Le 22/09/2011 16:10, Dr. Stephen Henson a écrit : On Thu, Sep 22, 2011, Erwann Abalea wrote: [...] In your examples, you set version to 3. Based on your parsed example, it seems you correctly set the tag ([1]) for the crls element, but you didn't use the good encoding for the other field (of type OtherRevocationInfoFormat, as it also must be tagged ([1]) and be identified by the correct OID (1.3.6.1.5.5.7.16.2). That agrees with my analysis. OpenSSL is choking on that field because it is expecting a CRL. Exactly. You seem to be fluent in OpenSSL ;) Note that OpenSSL doesn't enfornce the version value in the parser. Strict on emitting, relax on receiving-motto. But not relax enough to be able to recognize an OCSP token in a CertificateList. Shame. (just kidding, not cafeinated enough) -- Erwann ABALEA - Bien reçu message via groupes discussion, je te répond avec la touche répondre au groupe en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: [openssl-dev] openssl.org web site certificate renewed
Bonjour, Hodie III Kal. Sep. MMXI, Jakob Bohm scripsit: [...] 1) The CA has changed/improved the attributes, e.g. by extending the expiry date or adding a CRL location for detecting future root cert revocation (a good precaution for CA's to take, coupled with a pre-generated key compromise CRL stored somewhere off-site but secure). The relying party won't automatically update its trust store when receiving such a certificate, even if the key is reused. So it won't trust this new certificate, and won't use it to build a valid certification path. But you can of course manually grab it for this: 2) My browser lacks the CA cert, in which case having it at hand eliminates one of the two steps in securely adding it (the other step is to compare the cert hash (fingerprint) with a known published value). Is that really useful? Always sending a useless certificate in case someone would need it and use openssl s_client -connect ... -showcerts to update its database, instead of providing a link to this certificate somewhere? -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: users auth. in XP for HTTPS
Hodie III Kal. Sep. MMXI, Jakob Bohm scripsit: On 8/30/2011 3:29 AM, Dave Thompson wrote: ... That sounds like the keyUsage bit dataEncipherment, and OpenSSL CA can set it. But SSL never *does* dataEncipherment using a certificate/key, so this bit should not be needed or make any difference. Small correction: SSL/TLS never does dataEncipherment with *client* certificates, and always does dataEncipherment with *server* certificates (if any). Correction to the correction: TLS always does dataEncipherment with server certificate *if* the key exchange algorithm is RSA. So dataEncipherment should be set in the SSL server certificate and clear in the SSL client certificate, as is apparently already the case here, so that part is OK. Even if you don't set the dataEncipherment bit in the keyUsage extension, it works. TLS libraries are tolerant :) -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - It works better if you plug it in where it should be. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] openssl.org web site certificate renewed
Bonjour, Hodie III Kal. Sep. MMXI, Lutz Jaenicke scripsit: I have just installed a new 3 year wildcard *.openssl.org certificate to our web site. Thanks to GlobalSign for the new donation. The migration should work more or less unnoted for the users. If you experience any problems please drop me a message. Thanks to them, yes. Maybe you could remove the root CA from file designed by the SSLCertificateChainFile directive? It's useless to send it to the client, as you know, and you may gain 1 TCP packet (+ ACK in return) during the negotiation. You should also disable SSLv2, and 128bits ciphers. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] loadbalancer affinity/persistence with tls sessiontickets
Bonjour, Hodie VIII Kal. Sep. MMXI, Arjan Filius scripsit: Does one know it the tls sessionticket consept could work with loadbalancer afinity/persistence? It is perfectly suited to dumb loadbalancers. The session state is the ticket, and is saved by the client, encrypted by the server's private key. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Wget can't validate some certificates.
Hodie VII Id. Aug. MMXI, Kamil Jońca scripsit: I have weird problem with some sites using ssl. Mozilla _can_ validate certificate but wget can't, and I don't know if it is a debian bug or openssl. Whole story begins at http://lists.debian.org/debian-user/2011/06/msg00089.html The certificate chain sent by the website is this: 0. s:/1.3.6.1.4.1.311.60.2.1.3=PL/2.5.4.15=Private Organization/serialNumber=008723/C=PL/postalCode=50-950/ST=Dolnoslaskie/L=Wroclaw/streetAddress=ul. Rynek 9/11/O=Bank Zachodni WBK S.A./OU=Obszar Operacji Bankowych/CN=www.centrum24.pl i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA issuer hash bae2cbd8/ac12bd91 1. s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 subject hash bae2cbd8/ac12bd91 issuer hash facacbc6/b204d74a 2. s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority subject hash facacbc6/b204d74a issuer hash 7651b327/415660c1 Your wget binary wants to validate the certificate sent in position 2, which is signed by a previous VeriSign Root CA. So it looks for a file or link named 415660c1.0 in the /usr/lib/ssl/certs/ directory, and can't find it. Are you sure it doesn't look for a file or link named b204d74a.0 in the same directory, after that? Normally, it should try to validate the position 1 certificate with its certificate store. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to do a PKCS#10 in embedded systems
Bonjour Giordano Hodie Non. Aug. MMXI, Giordano Bruno scripsit: I tried your command, but I got an error: C:\OpenSSL-Win32\binopenssl rsautl -in example.der.sig -inkey example.key -pubin -verify -hexdump –raw Loading 'screen' into random state - done unable to load Public Key You first have to create the necessary files, extracted from the request (since it is self-signed). I read the PKCS#1, PKCS#8, PKCS#7 and PKCS#10 and now I have an better idea from PKI, but I'm still a begginer in these contents. Could you tell-me how to make the example.key and example.der.sig? Is it in Base64 encoding? Let's start with your example file: example.der. Extract the contained public key: openssl req -pubkey -inform D -in example.der -noout example.key Now we'll extract the signature block. Start by ASN1-parse your file: openssl asn1parse -inform D -i -dump -in example.der You'll see the subject name, public key, extension requests, and the signature at the end: 318:d=1 hl=3 l= 129 prim: BIT STRING - 00 8f 2c 23 95 d5 70 b6-19 df 20 fb 59 a6 e8 9f ..,#..p... .Y... 0010 - 5d 59 0b b5 33 69 6b ee-8b 4f 4e f8 1a 4d be 12 ]Y..3ik..ON..M.. 0020 - 30 5b 8b 1c bf 3b 09 9b-62 9c 00 a9 47 91 0d 06 0[...;..b...G... 0030 - a4 3f 6e e7 a4 77 32 f4-ca 09 c7 1a b2 2f e8 62 .?n..w2../.b 0040 - c7 43 b1 0e a4 fe d6 61-fa 6c 43 81 3e af de a9 .C.a.lC 0050 - 79 2d 72 b5 3a bc 00 01-59 d3 86 59 45 7a 28 54 y-r.:...Y..YEz(T 0060 - 55 c6 b7 45 c0 22 96 6c-7a b1 a3 b7 f5 3f e2 5f U..E..lz?._ 0070 - c9 96 b0 b8 2c 3c dc b8-9b 0b c0 e5 77 41 5a ae ,..wAZ. 0080 - 61a You know that the signature starts at offset 318. We need only the raw signature, so we'll skip the first 318 bytes, the header (hl=3, so skip 3 more bytes), and since it's a bit string, it starts with the number of unused bits (expressed in one octet, 00 in this case), you must also skip this octet. Finally, you need to skip 318+3+1=322 bytes: dd if=example.der of=example.der.sig bs=1 skip=322 The command should tell you that it has extracted 128 bytes, which is the size of your 1024bits RSA signature. Since you're working under Windows, you'll need to find a dd binary, or do the operation on a Unix-like machine. Now, you can perform the raw RSA verification: openssl rsautl -in example.der.sig -inkey example.key -pubin -verify -raw -hexdump And you'll get the data that was passed to your signature function: - 32 dc d5 61 c5 88 4a 00-b3 a9 9b c2 61 ce d6 01 2..a..J.a... 0010 - f6 b4 83 9b 60 0f 7d 99-15 34 e6 47 98 2b 06 5a `.}..4.G.+.Z 0020 - cc 07 39 c6 f7 87 f4 75-6e 1a 16 5b 32 70 5a a3 ..9un..[2pZ. 0030 - 5e 42 c0 71 02 4c a3 1d-48 31 7c 7c 12 bb 3f e6 ^B.q.L..H1||..?. 0040 - c4 4d e7 dc 43 80 0e b8-fe cb ba 15 b6 1e 8c 3d .M..C..= 0050 - 1b 98 31 04 23 51 9d 26-d7 ac fc a5 6d 47 6a 4f ..1.#Q.mGjO 0060 - 9d bb 12 e3 e0 44 c7 4d-23 4c c0 49 a6 40 fe 38 .D.M#L.I.@.8 0070 - e7 ab 48 f6 a3 f3 a5 a6-1a 11 bb 1b 94 d9 e0 bc ..H. You then can manually verify the padding, hash algo, hash value, etc. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to do a PKCS#10 in embedded systems
Hodie pr. Non. Aug. MMXI, Giordano Bruno scripsit: Hi people, I have a problem in in certifications in low level issue, but I think it is the best place to solve, I need to generate a PKCS#10 with a very limited device, a MSP430F5438 from Texas Instruments plus a co-processor that implement the RSA and SHA-1 algorithms. The coprocessor generate the key pair, as shown below. I used the private key generate to sign the part in the of the CSR message. I used RSA 1024 with SHA-1 algorithms to do this. As result we got the file example.der. I used the site http://www.motobit.com/util/base64-decoder-encoder.asp to transform the DER file in the example.pem. To validate this information, I use the site http://www.redkestrel.co.uk/cgi/decodeCSR.cgi, achieving as result the warning The CSR has an invalid signature. The signature is really invalid. I took your DER file, extracted the signature block on one side, extracted the public key on the other side, and performed the raw RSA verification operation: openssl rsautl -in example.der.sig -inkey example.key -pubin -verify -hexdump -raw - 32 dc d5 61 c5 88 4a 00-b3 a9 9b c2 61 ce d6 01 2..a..J.a... 0010 - f6 b4 83 9b 60 0f 7d 99-15 34 e6 47 98 2b 06 5a `.}..4.G.+.Z 0020 - cc 07 39 c6 f7 87 f4 75-6e 1a 16 5b 32 70 5a a3 ..9un..[2pZ. 0030 - 5e 42 c0 71 02 4c a3 1d-48 31 7c 7c 12 bb 3f e6 ^B.q.L..H1||..?. 0040 - c4 4d e7 dc 43 80 0e b8-fe cb ba 15 b6 1e 8c 3d .M..C..= 0050 - 1b 98 31 04 23 51 9d 26-d7 ac fc a5 6d 47 6a 4f ..1.#Q.mGjO 0060 - 9d bb 12 e3 e0 44 c7 4d-23 4c c0 49 a6 40 fe 38 .D.M#L.I.@.8 0070 - e7 ab 48 f6 a3 f3 a5 a6-1a 11 bb 1b 94 d9 e0 bc ..H. This isn't a valid signature (02, padding, DER sequence with hash OID and value). Are you sure of your public key? -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to do a PKCS#10 in embedded systems
Bonjour,
Hodie pr. Non. Aug. MMXI, Giordano Bruno scripsit:
Thank you for reply,
I didn't understand what you mean with this sequence (02, padding, DER
sequence with hash OID and value). Can you explain?
The hash of our der file (without the first header, the signature
header and the signature) should be the expected result of your
command (openssl rsautl -in example.der.sig -inkey example.key -pubin
-verify -hexdump -raw)?
The command I used displays the integer that has been signed in the
RSA process. So yes, the hash of your data should have been embedded
in this result, encapsulated in a structure.
I made a mistake, it doesn't start with 02, but with 00 01. Here's an
example of a valid before signature block, signed by a 2048bits RSA
key, with the sha1withRSA signature scheme (I got this with the same
command, obviously on other data):
00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff 00 30 21 30
09 06 05 2b 0e 03 02 1a 05 00 04 14 80 08 3f d2
05 06 6b e1 0a f3 75 39 70 d2 5b 57 01 37 2c df
Everything is described by the PKCS#1 standard, and the text is freely
available. You should be able to recognize the following structure:
30 21 SEQUENCE {
30 09 SEQUENCE {
06 05 2b 0e 03 01 1a OID (sha1)
05 00 NULL
}
04 14 ... 2c df OCTET STRING (the hash value)
}
Download and read PKCS#1, and you'll have a better understanding.
--
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France
Tél.: +33 1 55 64 22 07
http://www.keynectis.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: revoking crt
Hodie XIV Kal. Aug. MMXI, y...@inbox.lv scripsit: If that CRL is trying to revoke that root certificate, what in that CRL could ber forged? If that CRL tells the private key is compromised, how could you trust this CRL (since it was signed by a compromised private key)? CRL can only revoke a CRT, not unrevoke, right? Yes, it can. A CRL is a present state of revoked certificates. Remove a certificate's serial number from a CRL, it is no longer revoked. A root CA can not be revoked, that's all. Think of revocation as an automatic way to suspend trust in a certificate. PKI only transfers trust, it doesn't create it. The trust that is transferred (by signing and/or revoking certificates) is explicitely (and manually) placed into the root, by an off-band method. Revocation of the root would consist of removal of this trust, and as it was manually added, it also must be manually removed. I know, that when revoking a certificate, CRL is signed by certificate issuer (CA), is there a reason, why a (small) CRL could not be signed by cartificate itself? CRL scope. Read X.509. (after all, anyone using leaked private key would be intereseted to delay revocation, but they have no means of preventing it) -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - All wiyht. Rho sritched mg kegtops awound? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OCSP request / response over HTTP-GET
Hodie V Kal. Iul. MMXI, Sugimoto, Koichi - GlobalSign K.K. scripsit: It seems that OpenSSL does not compliant to RFC 5019. Are there anyone prepareing to develop HTTP-GET based OCSP command? As for server, malformedRequest (1) is returned if received HTTP-GET based ocsp request. RFC5019 is The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. OpenSSL as a command-line tool can't be used in a high volume environment (in fact, it quits when it receives anything else than POST as a verb). If you have such needs, then you're able to write your own, using OpenSSL API. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] cipher suite ECDH-ECDSA-AES128-SHA256
Bonjour, Hodie VIII Kal. Iun. MMXI, shoutee scripsit: I want to run a TLS Server with support of cipher suite 'ECDH-ECDSA-AES128-SHA256' (RFC 5289). Unfortunately I can't find these cipher suite within tls1.h. ECDSA is only available with SHA1. Since openssl supports SHA256 I thought that ECDSA with SHA256 should be available, or am I missing something? I'm using openssl-1.0.0d. The ciphersuites defined in RFC5289 apply to TLS1.2 only. OpenSSL doesn't support (yet) TLS1.2. If your next question is when will OpenSSL support TLS1.2?, you'll find the answer in the archives, as it has been asked quite some times. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - Architect: Someone who knows the difference between that which could be done and that which should be done. Larry McVoy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] cipher suite ECDH-ECDSA-AES128-SHA256
Bonjour, Hodie VIII Kal. Iun. MMXI, Dr. Stephen Henson scripsit: On Wed, May 25, 2011, Erwann ABALEA wrote: Hodie VIII Kal. Iun. MMXI, shoutee scripsit: I want to run a TLS Server with support of cipher suite 'ECDH-ECDSA-AES128-SHA256' (RFC 5289). Unfortunately I can't find these cipher suite within tls1.h. ECDSA is only available with SHA1. Since openssl supports SHA256 I thought that ECDSA with SHA256 should be available, or am I missing something? I'm using openssl-1.0.0d. The ciphersuites defined in RFC5289 apply to TLS1.2 only. OpenSSL doesn't support (yet) TLS1.2. If your next question is when will OpenSSL support TLS1.2?, you'll find the answer in the archives, as it has been asked quite some times. The answer however has changed: experimental TLS v1.2 code is present in HEAD and the 1.0.1 stable branch. The code hasn't been fully tested yet so some I forgot that, it was mentioned once recently, you're right. Was that work funded, or did some developer dedicate some spare time for this? If anyone knows of any public servers supporting TLS v1.2 I'd be interested in some interop testing. If you can install a recent IIS, you'll have TLS1.2. Recent versions of GNUTLS also support TLS1.2. IE9 (probably on Windows 7) also supports TLS1.2, if you want to test the server part. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - Stupidity has no limits, genius does. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hodie XIV Kal. Iun. MMXI, Dave Thompson scripsit: From: owner-openssl-us...@openssl.org On Behalf Of Erwann ABALEA Sent: Thursday, 19 May, 2011 04:20 Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: snip: renew CA The only way I found was to give the new Root Certificate the same serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. There are (at least) two kinds of AuthorityKeyIdentifier. AKI=SKI identifies only the parent (CA) key (by hash), and is ambiguous if CA gets new cert for same key. AKI=issuerSerial *does* use parent (CA) serial. You're right, the AKI extension can be populated with these 2 informations (in fact, really 3, but 2 of them are linked together in the X.509, and not in RFC5280). -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - ``Do or do not. There is no try. Yoda __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: On 05/18/2011 11:17 AM, Erwann ABALEA wrote: Bonjour, Hodie XV Kal. Iun. MMXI, Jean-Ann GUEGAN scripsit: Hi ! It’s possible to renew a Certificate Autority or extend the date validity ? These 2 options are possible. Recertify (i.e. sign the same certificate, but change the serial number and validity dates) is the least problematic solution, as the same public key will be used to validate the certificates and CRLs. Renew (i.e. create a entirely new certificate, strictly keeping the same exact subject DN, changing the key, validity dates, and potentially the extensions) is covered by the X.509 standard (a CA is a name, not a certificate). Sadly, you can't be sure it's correctly dealt with by verifiers. The new objects (certificates and CRLs) will be signed by the new CA key, the CRLs will cover both old and new certificates (by old, I mean those signed by the old CA certificate). If your CA is a root, and you want RFC5280 compliance, you MUST produce one CRL for each root CA certificate (and adapt the crlDistributionPoints). There seems to be a problem with this if you have AKID and SKID in place. Certificates signed with the old Root Certificate will be bound to the old Root Certificate serial number. You can verify this with the output of openssl x509 at the X509v3 extensions section. old end-user certificates can only be verified by the old CA certificate, of course (in case the CA is renewed, with its key changed, etc). The only way I found was to give the new Root Certificate the same serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. openssl req -new -x509 -days 1000 -key cakey.pem \ -set_serial old id in decimal -out new_cacert.pem After that, verification of already signed certificates is working fine with the old and new Root Certificate. Did you change the private key of the CA? If not, then: - the SKI of the new CA certificate will be the same as the old certificate (it's a *Key* identifier, and is generally constructed from the public key) - you don't need to have the same serial number (remember, it's forbidden by X.509 standard) - you will be able to verify old end-user certificates with the new CA certificate (since the CA key didn't change), if the rest of the CA certificate permits it (validity dates, extensions). If you were in this situation, and only were able to verify end-user certificates if the new CA certificate had the same serial number as the old one, then I'm sure you made a mistake in your tests. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - Press Control-Alt-$ to appease spirits. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Bonjour, Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: I do apologise - it's a long post. I'm just not totally sure if I have the correct attributes and extensions - and whether it meets the requirements of a v3 SSL cert (I think it does). Is 4096 bit key and sha1 a good choice? SHA1 is still tolerated, but being slowly obsolete. You can still use it if your serial numbers have some randomness, which is not the case here. Either use one member of the SHA2 family, or generate random serial numbers. And is the revocation bit done correctly (assuming I actually maintain a CRL from openssl ca -gencrl at the url above? All the ns* extensions are deprecated, and shouldn't be used anymore. The nsCaRevocationUrl extension should be replaced by this: crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl You don't need to place a CRLDP extension in the root CA certificate (a root can't really revoke itself). You forgot to place the keyUsage extension in your server certificates. The issuerAltName extension is useless as stated (I'd say it's also useless in general, but I won't argue). I'd set the critical flag for the basicConstraints extension (both CA and end-users (server+user)). -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - Your mouse has moved. Please reboot to continue. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Bonjour Tim, Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: On 19/05/11 13:03, Erwann ABALEA wrote: [...] SHA1 is still tolerated, but being slowly obsolete. You can still use it if your serial numbers have some randomness, which is not the case here. Either use one member of the SHA2 family, or generate random serial numbers. Hi Erwann, Thanks for that. I'm not sure how to do random serials (I let openssl manage those) but it interesting to know it makes a difference. This how I do this: - in the setup phase, after having generated the CA private key, generate a secret key (16 random bytes taken from /dev/urandom will suffice), and place this key into CAdir/private/secretkey; I also create a file named counter, in the same directory as the serial one, and init it with an echo 1 /counter - when I want to sign a certificate, do this: SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr 'a-f' 'A-F'` COUNTER=`cat DIRECTORY/counter` echo `expr $COUNTER + 1` DIRECTORY/counter SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv -aes-128-cbc | od -t x1 -A n | sed 's/ //g' | tr 'a-f' 'A-F'` SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l` and then either: - use -set_serial $SERIAL if you produce a self-signed certificate with the openssl req command - do echo $SERIAL DIRECTORY/serial, and run the openssl ca command as usual That way, the serial number is random for the outside, is guaranted to be unique, and stays deterministic for you (decrypt it with your secret key, and you'll be able to know which number it is, if you need). Using random serial numbers is interesting if the hash function is no more collision resistant (MD5 isn't, SHA1 is still up, but not for so long). [...] The nsCaRevocationUrl extension should be replaced by this: crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl OK - cool. Should I support both do you think for backwards compatibility? Just use crlDistributionPoints, everybody wanting to download a CRL will do this from this extension. This ns (netscape) extension is of no use. The issuerAltName extension is useless as stated (I'd say it's also useless in general, but I won't argue). What should it be in this context? Don't use this extension, unless you want to name your CA with another name as the one given in its issuerName :) [...] This is one of those jobs that I assign the want to do it right flag too - I have a 100 servers that eventually need new certs (though I will probably be forced to use a wildcard CN on most of them as many do name based virtual hosting on apache - yes I know, the RFCs only mention wildcard CNs in the context of a few services and not specifically HTTPS, but what can you do...) Cheers, Tim I read an interesting blog by a google employee on the issue of CRLs and avoiding the whole issue by setting up automatic distribution of very short time-to-live certs: http://www.imperialviolet.org/2011/03/18/revocation.html (Adam is an ex-student of the uni I used to work at - a very sharp fellow indeed). That's an interesting point. The author could have given more detailed information, as some browsers use the native OS crypto API (for example IE, Chrome or Safari), or use NSS when nothing is provided by the OS (Chrome on Linux), or use their own crypto API (NSS for Firefox, something else for Opera). The revocation validation is generally performed by the used crypto API. To simplify it a little more, EV behaviour is not imposed by this API, and is proprietary to the browser. You can surely deliver short-lived certificates, but you'll have to renew them more often, and deploy them, etc. That's a lot of work :) This solution has also be mentioned in the Mozilla CA Policy group. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - If at first you don't succeed; Blame everyone else __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Bonjour Tim, Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: On 19/05/11 14:48, Erwann ABALEA wrote: Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: Thanks for that. I'm not sure how to do random serials (I let openssl manage those) but it interesting to know it makes a difference. This how I do this: - in the setup phase, after having generated the CA private key, generate a secret key (16 random bytes taken from /dev/urandom will suffice), and place this key intoCAdir/private/secretkey; I also create a file named counter, in the same directory as the serial one, and init it with an echo 1 /counter - when I want to sign a certificate, do this: SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr 'a-f' 'A-F'` COUNTER=`cat DIRECTORY/counter` echo `expr $COUNTER + 1` DIRECTORY/counter SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv -aes-128-cbc | od -t x1 -A n | sed 's/ //g' | tr 'a-f' 'A-F'` SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l` and then either: - use -set_serial $SERIAL if you produce a self-signed certificate with the openssl req command - do echo $SERIAL DIRECTORY/serial, and run the openssl ca command as usual I presume there is a slight possibility of a serial number clash with that? Not that it's a problem, but it would be wise to check index.txt to see if the number has been used before? Really, no. A counter is encrypted, and the result of the encryption is the serial number. If you imagine a collision in this serial number generation scheme, then it means that a ciphertext (serial number) can be decrypted into 2 different plaintexts (counter). That's impossible if the secret key is constant. The problem with this scheme is that it doesn't deal well with parallel certificate signatures. You have one shared information that must be incremented in an atomic way. But for a Junk CA (that's how I call the set of scripts I use), that's not a problem. You could have used another scheme: - generate 16 random bytes - place them in the serialNumber With such a scheme, yes, a collision could occur, and you should check the index.txt file first. Beware of the ca command line tool if you have a large population. I wanted to use it for a massive certificate generation (in order to fill an LDAP directory), and the time taken to generate a certificate goes larger with the number of generated certificates (it must load the file into memory, check if the given name either doesn't exist or exists only with revoked or expired certificates, extend the list, and finally write it again onto disk). [...] You can surely deliver short-lived certificates, but you'll have to renew them more often, and deploy them, etc. That's a lot of work :) This solution has also be mentioned in the Mozilla CA Policy group. I have a masterplan for that :) I have, out of necessity, a very secure gold server that has access to everything else (it will become the master Kerberos server one day and also needs to auto distribute kerberos keys when that happens). It is extremely well protected - which means the issue of caching the CA passphrase on it is moot (if anyone hacks that server, they own everything anyway - SSL will be the least of our problems - a point that is generally true of any master authentication or config management server even without the additional abilities this one has). The infrastructure I envisage is one where a database will have a record of all SSL enabled services and cert/key file locations plus CN information - which makes it practical to run and distribute by itself - which then makes Adam's idea viable. Then this deployment server will be your SPOF :) -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - ``It's nice to be important, but it's important to be nice.'' Anon. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: On 19/05/11 16:46, Peter Sylvester wrote: another approach is to take the value of 'time' (the current second) and append to it the current process number, and, in case of several machines, some number indicating the id of the machine. instead of the process number, any other method to ensure uniqueness within a second may be used. Ah yes - that would guarantee a non repeating unpredictable sequence. I was confuse initially as I did not realise the serial number could be so big (16 bytes was it?). 20 bytes max, for the RFC5280. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS - If you never try anything new, you'll miss out on many of life's great disappointments. Demotivators, 2002 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Bonjour, Hodie XV Kal. Iun. MMXI, Jean-Ann GUEGAN scripsit: Hi ! It’s possible to renew a Certificate Autority or extend the date validity ? These 2 options are possible. Recertify (i.e. sign the same certificate, but change the serial number and validity dates) is the least problematic solution, as the same public key will be used to validate the certificates and CRLs. Renew (i.e. create a entirely new certificate, strictly keeping the same exact subject DN, changing the key, validity dates, and potentially the extensions) is covered by the X.509 standard (a CA is a name, not a certificate). Sadly, you can't be sure it's correctly dealt with by verifiers. The new objects (certificates and CRLs) will be signed by the new CA key, the CRLs will cover both old and new certificates (by old, I mean those signed by the old CA certificate). If your CA is a root, and you want RFC5280 compliance, you MUST produce one CRL for each root CA certificate (and adapt the crlDistributionPoints). -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Possibility to create CRL without the CA key
Hodie IV Non. Mai. MMXI, Viliam Ďurina scripsit: Thanks very much for the hints. Finally, I decided to generate CRL for three years and replace it, when something needs to be revoked, if ever. I think the support is not good. We will have to distribute the CRL issuer certificate to partner applications to be able to verify the CRL signature. And generally, the support and knowledge about indirect crl is low among developers... That could lead to a problem with crypto toolkits that try to fetch a new CRL only when the actual has expired (it was a common behaviour some years ago, I don't know how this evolved). You could also pre-generate several CRLs, with a 1 month validity period, and disclose a new one regularly. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - Mammifère : se dit d'un animal à squelette, poilu, qui donne du lait. Exemple : une noix de coco. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: How to disable index and serial?
Hodie pr. Id. Ian. MMXI, Mark H. Wood scripsit: On Tue, Jan 11, 2011 at 07:23:54PM +0100, Erwann ABALEA wrote: In order to be referenced by browser vendors (Opera comes to mind, and I think Mozilla will require this), the serial number MUST be random (or at least *appear* random from the outside). Oh, now I'm curious. How do they test the randomness of a single sample? 1 is every bit as random (or nonrandom) as 0xdcb4a459f014617692d112f0942c89cb. That's not how it's done. When you apply for your Root CA to be referenced in a product, you supply your CP and CPS, and audit results. That's the auditor's job to ask how the serial is generated, in order to check that you really do what you say you do. Lying during the audit is of course technically possible, but it will surely be discovered one day, and you'll lose your business. -- Erwann ABALEA erwann.aba...@keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: How to disable index and serial?
Hodie III Id. Ian. MMXI, Peter Sylvester scripsit: by using the command x509 and not ca for example. you can use a serial number based on a date seconds plus processid for example) to guarantee uniqueness. More on this. A serial number MUST be unique (by X.509 design), and SHOULD be random (best practices, to avoid attacks with non collision-resistant hash functions). In order to be referenced by browser vendors (Opera comes to mind, and I think Mozilla will require this), the serial number MUST be random (or at least *appear* random from the outside). -- Erwann ABALEA erwann.aba...@keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OCSP Success even cert alredy expired
Hodie IV Non. Oct. MMX, shizumi scripsit: i using openssl test tool by using this command openssl.exe ocsp -issuer issuer.pem -CAfile CACert.pem -cert Certificate.pem -url http://192.168.0.235:8080/myCA/publicweb/status/ocsp my CACert and issuer cert already expired. If either the CA cert or the user cert has expired, then asking for a revocation status is not necessary, the certificate is not currently valid. X.509 standard says that the CA warrants to maintain information about the status of the certificate during its valitidy period (validity of the issued certificate). but it still return me respond verify OK. i see in my ca server. it show me error cannot found in database Strange. Are you sure you're asking the right CA? Did you use the -updatedb option of openssl ca command, to delete expired certificates from its database? If yes, then you've got the reason of this message. From the CA, it's dangerous to reply with an OK status when this certificate can't be found (an unknown status would be better). But in the end, everything has expired, so that's not really a problem. -- Erwann ABALEA erwann.aba...@keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Creating Extended Validation SSL Certificates
Bonjour, Hodie V Kal. Oct. MMX, Gumbie scripsit: I apologize to all for not looking into this more, before asking. It isn't just a matter of adding the proper extensions. The various browser software actually has the corporate policy OID hard coded into the browser code. At first glance I would never of thought this, as the delay to getting your product to the web market may be a factor. Please be more explicit about your product. Is your product a device? A server? If yes, then the delay is clearly not an issue, an EV certificate can be bought and delivered in 1 or 2 days, if you're ready for the necessary validations (EV stands for Extended Validation). Again unless you pay outrageous fees for basically getting a notary seal from one of the certificate CA's that have their policy already in place or you're out of luck! Outrageous fees? A free SSL certificate is exactly of this value. Zero, as nearly no verification is performed, or they're completely automatic ones (i.e. send a challenge to a predefined email address, wait for the answer, update the database to say 'OK, this guy controls this address'). An EV certificate costs money: - robust facility, with safes, HSM, access controls, guaranteed connectivity (to provide revocation information), redundant sites - trained employees, and employees background screening (done on a regular basis) - up-to-date procedures; you seem to have downloaded the 1.0 version of the guidelines, dated 2007, an 1.2 version is already out, some work is currently done to update it; CAs must follow this work, and be informed about cryptography advances - enrollment of the CA on end-user products (some of them require work to be done, some of them require payment) - most sensible operations performed under screening and validation of a notary (namely key ceremonies) - audits performed each year - certificate request validations performed manually (i.e. by humans), with access to different information repositories (some of them may not be free), contact of the entity requesting the certificate, gathering and controlling necessary documents (ID information, for example) - usually using a proprietary software, written by the company itself, with quality controls, certifications, documentation, testing, etc. All this has a price. Try to live in a free world if you want to, but be prepared not to get paid at all. Again it's not the fact you have to meet the guidelines, my issue is with the fees places like (no names mentioned) charge for certificates. I do think they should get paid for work done, but I don't think the current fees are in proportion with the product / service provided... I think you should have looked a bit more into it, before complaining :) Sorry if I offended anyone, No offense, really. (We provide EV certificates, among other things, and everything described above is really done) -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Creating Extended Validation SSL Certificates
Hodie IX Kal. Oct. MMX, Gumbie scripsit: Can someone explain what is needed to create and EV (Extended Validation) Certificate? I have been trying to research this and have found limited information on this. Only one document that was of any help -àhttp://www.cabforum.org/EV_Certificate_Guidelines.pdf. That's the only necessary document for technical issues. My issue is with OpenSSL and adding the needed additional OIDs to the certificate. Using OpenSSL and adding additional OIDs is not sufficient for a certificate to be EV with a green bar. You need your CA to be integrated in supported browsers as an EV-compliant one, and for this, you need to be audited, have correct validation procedures, have a correct facility, etc. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
