Re: parsing invalid DER
On 01/09/2022 18:15, Matt Caswell wrote: On 01/09/2022 13:21, Dave Coombs via openssl-users wrote: So! Is it possible to work around these, using ASN1_MACRO trickery or what-have-you? It's pretty clear I should end up with an empty bit- string and integer value 0x42, so is there a way to loosen the parser's pickiness and achieve this? Unfortunately, AFAIK, I don't think there is a way to do this. Matt Hi, I would try to patch two routines. I vaguely remember that openssl's integer decoder was eating a leading 0 octet in a positive integer decoding. but that seems to be fixed. code is in routine c2i_ibuf in crypto/asn1/a_int.c 0301xx look what ossl_c2i_ASN1_BIT_STRING in a_bitstr.c Don't test for bits when length is 1 Best Peter
Re: Why does OpenSSL report google's certificate is "self-signed"?
On 01/04/2021 16:21, Michael Wojcik wrote: Thanks to everyone who responded. You've confirmed my impression: - There doesn't appear to be any applicable standard which requires or forbids including the root, or even endorses or discourages it). rfc8446 page 65: The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify the one immediately preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.
Re: ASN.1 encoding error
Even with sound this would not be BER. i:-) Integers can have 9 or more leading zero bits in BERnot ISO/IEC 8825-1:2008 (E) ITU-T Rec. X.690 (11/2008) 7 8.3 Encoding of an integer value 8.3.1The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.3.2If 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.3The 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 bit1 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. On 25/02/2021 18:28, Benjamin Kaduk via openssl-users wrote: That sounds like the certificate is encoded using ASN.1 BER rules, that openssl accepts, but the python library is insisting on DER encoding (per the spec). -Ben On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users wrote: Hi all, I'm encountering an error connecting to a device which as far as I can see has a reasonable certificate... The error coming back (through twisted and python) is: twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', 'tls_process_server_certificate', 'ASN1 lib')] However if I run the following: # openssl s_client -connect : /dev/null | openssl x509 | openssl asn1parse 0:d=0 hl=4 l= 733 cons: SEQUENCE 4:d=1 hl=4 l= 453 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 4 prim: INTEGER :00 19:d=2 hl=2 l= 13 cons: SEQUENCE 21:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption ... (continues) ...then OpenSSL seems to handle the whole certificate without problem, the thing that looks "off" to me is the serial number being defined as "00", rather than "00" (which I see on the self signed certificates from other devices of this type). Is that likely to be causing the issue? It's ~20 years since I last had to deal with ASN.1 properly, so I can't remember if using unnecessarily long representations of integers is actually valid. The raw ASN.1 looks ok I *think* (although I note that it has four bytes specified) "02 04 00 00 00 00" I'm at the point where I might just try to get it to generate a new certificate and see if it does that with a single byte zero (as per the other similar device I've been looking at) Am I completely barking up the wrong tree, is there something else that I can use other than the asn1parse option to figure out where the error might be coming from? Cheers, John -- *John Robson*
Re: building openssl-1.1.1d with "enable-deprecated"
Hi Matt, I said " It does not work" means, after I build the open-ssl1.1.1d with or without the "enable-deprecated" configuration, then use the library, header files in my application as before with the older version(1.0.2t), then my build failed, the errors are like: Error C3861 'HMAC_CTX_init': identifier not found Error C3861 'HMAC_CTX_cleanup': identifier not found and more related to some struct def difference. But as I imagine, it should not happen, right ? Peter On Mon, Sep 16, 2019 at 11:17 AM Michael Wojcik < michael.woj...@microfocus.com> wrote: > Matt has answered the main question, but as an aside: > -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's > Visual C compiler for using various standard C library functions, rather > than using the optional "secure" ones (a misnomer, as they are at best > somewhat easier to use safely) added with C99 (in Appendix K of the C > standard, I think; I'm traveling and don't have my copy handy). It has > nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces > noise from the Microsoft compiler. >
Re: building openssl-1.1.1d with "enable-deprecated"
Hi Matt, So you are saying configuring with "enable-deprecated" or not won't make the build different, they are all actually support the deprecated functions, right ? If yes, then in my application , if I have "OPENSSL_USE_DEPRECATED" defined, the depecated functions in my application should still work, right? But it does not work. And as I imagine, in the openssl header files(after a successful build), it should have some "#if defines OPENSSL_USE_DEPRECATED" like statement, but I don't see it anywhere, can you tell me how it works? Thanks! Peter On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell wrote: > > > On 16/09/2019 15:44, Peter Sui wrote: > > Hi, > >From the openssl website, I got the folloeing instruction: > > " > > Access to deprecated functions/macros has been removed by default. To > enable > > access you must do two things. 1) Build OpenSSL with deprecation support > (pass > > "enable-deprecated" as an argument to config) 2) Applications must define > > "OPENSSL_USE_DEPRECATED" before including OpenSSL header files. > > " > > But, after I followed the instructions, it did not work. I searched all > the > > files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED" > anywhere. And > > in the make file generated, I found it's using the > > flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions > > available in the library built? I also compared all the binary and > header files > > between the build without "enable-deprecated" and the build > > with "enable-deprecated", there is no difference. > > The command I used is: > > perl Configure VC-WIN32 enable-deprecated > > --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015 > > nmake > > > > That CHANGES entry is incorrect and out-of-date. It should probably be > removed. > The original CHANGES entry said this: > > *) config has been changed so that by default OPENSSL_NO_DEPRECATED is > used. > Access to deprecated functions can be re-enabled by running config > with > "enable-deprecated". In addition applications wishing to use > deprecated > functions must define OPENSSL_USE_DEPRECATED. Note that this new > behaviour > will, by default, disable some transitive includes that previously > existed > in the header files (e.g. ec.h will no longer, by default, include > bn.h) > [Matt Caswell] > > That CHANGES entry was added while 1.1.0 was being developed. However > before > 1.1.0 was released we changed our mind and added this CHANGES entry: > > *) Revert default OPENSSL_NO_DEPRECATED setting. Instead OpenSSL > continues to support deprecated interfaces in default builds. > However, applications are strongly advised to compile their > source files with -DOPENSSL_API_COMPAT=0x1010L, which hides > the declarations of all interfaces deprecated in 0.9.8, 1.0.0 > or the 1.1.0 releases. > > In environments in which all applications have been ported to > not use any deprecated interfaces OpenSSL's Configure script > should be used with the --api=1.1.0 option to entirely remove > support for the deprecated features from the library and > unconditionally disable them in the installed headers. > Essentially the same effect can be achieved with the "no-deprecated" > argument to Configure, except that this will always restrict > the build to just the latest API, rather than a fixed API > version. > > As applications are ported to future revisions of the API, > they should update their compile-time OPENSSL_API_COMPAT define > accordingly, but in most cases should be able to continue to > compile with later releases. > > The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are > 0x1000L and 0x00908000L, respectively. However those > versions did not support the OPENSSL_API_COMPAT feature, and > so applications are not typically tested for explicit support > of just the undeprecated features of either release. > [Viktor Dukhovni] > > Regards > > Matt >
RE: building openssl-1.1.1d with "enable-deprecated"
Hi, From the openssl website, I got the folloeing instruction: " Access to deprecated functions/macros has been removed by default. To enable access you must do two things. 1) Build OpenSSL with deprecation support (pass "enable-deprecated" as an argument to config) 2) Applications must define "OPENSSL_USE_DEPRECATED" before including OpenSSL header files. " But, after I followed the instructions, it did not work. I searched all the files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED" anywhere. And in the make file generated, I found it's using the flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions available in the library built? I also compared all the binary and header files between the build without "enable-deprecated" and the build with "enable-deprecated", there is no difference. The command I used is: perl Configure VC-WIN32 enable-deprecated --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015 nmake Thank you inadvance! Peter Sui
Re: Allow specifying the tag after AAD in CCM mode
I've commented on the PR, mostly about not understanding the commit message RFC-references and indentation error. Overall the PR looks good to me, but I'd like someone who is more familiar with implementation have a look at it. Best Regards Eine Kleine Blau Fisch On Tue, Feb 19, 2019 at 2:10 PM Tobias Nießen wrote: > > Hello everyone, > > in GCM and OCB mode, it is possible to set the authentication tag after > supplying AAD, but the CCM implementation does not allow that. This > isn't a problem for most applications, but in Node.js, we expose similar > APIs to interact with AEAD ciphers and these differences between cipher > modes within OpenSSL propagate to our users. Unless there is a reason > for the current behavior, I would prefer to change it. > > I opened a PR about this five months ago > (https://github.com/openssl/openssl/pull/7243). It has received zero > attention and I am hoping the mailing list is a good way to change that. > > Kind regards, > Tobias >
Re: [openssl-users] File permissions on keys, csr, and certificates
root:root, chmod 400. And ideally your Root CA files should not be hosted on your web server, otherwise a server compromise also compromises your root authority. https://redmine.lighttpd.net/projects/1/wiki/docs_ssl Permissions Be careful to keep your .pem file private! Lighttpd reads all pemfiles at startup, before dropping privileges. It is therefore best to make the pem file owned by root and readable by root only: $ chown root:root /etc/lighttpd/ssl/example.org.pem $ chmod 400 /etc/lighttpd/ssl/example.org.pem On Fri, Nov 9, 2018 at 10:04 PM Ikwyl6 via openssl-users wrote: > > Hi - I created a question on Super User about questions on file permissions > and what the file permissions should be on created files. See link here: > > https://superuser.com/questions/1368747/file-permissions-for-openssl-created-files-for-https-web-server-lighttpd > > Could someone comment on what file permissions should be on each file and who > should own them. > > Thank you. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is there any C code that implements SM2 algorithm separately?
You can find a number of SM2 implementations on github, etc. https://github.com/openssl/openssl/blob/9453b196343db579c590130adc63d35d2ff87188/crypto/sm2/sm2_crypt.c https://github.com/ARMmbed/mbedtls/blob/3ea8c4cb2a03724ba15c915e02d83255e1884859/library/ecdsa.c https://github.com/developerworks/sm2/blob/master/miracl/sm2.c Asymmetric ciphers are typically not "library free", because you need the big number operations. The big number operations should preferably secure versions that don't reveal private key through side-channels (timing etc), so these operations are usually are provided by a cryptographic library. On Fri, Nov 9, 2018 at 3:06 AM 朱明哲 wrote: > > Hi all, > > Is there any C code that implements SM2 algorithm separately, which means is > there a version in C language that is implemented independently of the > existing library of openssl? > Thanks a lot. > > Best Wishes. > > > > > > > -- > ___ > 朱明哲 > 电子邮箱:zhumz...@163.com > 手机号码:15651609020 > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
Thanks =) This is similar to other commands, e.g. ssh, tpm2-tools, etc inconsistencies between different flags between different sub-commands. Getting it right the first time is easier said than done and changing command line behaviour later on breaks user scripts etc. //P On Wed, Oct 17, 2018 at 10:13 AM Richard Levitte wrote: > > In message > on Tue, > 16 Oct 2018 10:34:31 +0200, Peter Magnusson > said: > > > Sorry, I am an idiot =) > > No you're not. > > > Problem resolved, user error. -key was the problem and should not be > > used as I showed. > > > > -key has a different meaning for openssl ca than for openssl req, so > > my PIN was my -key argument. It got my keyfile from the openssl conf > > file. > > And this is precisely why you're not an idiot. We're not consistent > between openssl sub-commands, so no wonder you get confused. It's a > pattern thing, we catch on to similar patterns (such as option names). > > We really should look over those options... (but with all the other > stuff we have going on, I'm afraid this isn't the highest on our > priority list) > > Cheers, > Richard > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
Sorry, I am an idiot =) Problem resolved, user error. -key was the problem and should not be used as I showed. -key has a different meaning for openssl ca than for openssl req, so my PIN was my -key argument. It got my keyfile from the openssl conf file. On Tue, Oct 16, 2018 at 10:23 AM Richard Levitte wrote: > > I'm curious about this error line from the 'openssl ca' output: > > > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too > > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters > > It should be interesting to try and figure out what pass phrased was > passed and where it came from. I'm afraid that's a debugging session. > > Cheers, > Richard > > In message > on Tue, > 16 Oct 2018 09:54:08 +0200, Peter Magnusson > said: > > > The error can be workaround by entering PIN = "..." into [pkcs11_section]. > > pkcs11 engine version is libp11-0.4.9. > > Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me > > doing something wrong? > > On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson > > wrote: > > > > > > Hi, > > > > > > I'm trying to understand how to make "openssl ca" prompt for a PKCS#11 > > > login pin. Version is openssl-1.1.1. > > > > > > openssl req works as I would expect, prompting for PIN: > > > > > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \ > > > local-build/bin/openssl \ > > > req -config yubihsm2-openssl.conf -new \ > > > -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out > > > certs.dir/ca.csr.pem > > > engine "pkcs11" set. > > > Enter PKCS#11 token PIN for YubiHSM: > > > > > > openssl ca I fail to get working, no prompt presented, tried adding > > > -passin stdin but that has no effect. > > > > > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \ > > > local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform > > > engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \ > > > -config yubihsm2-openssl.conf \ > > > -days 3650 -extensions vpn_server_cert \ > > > -out server.cert.pem \ > > > -infiles ../server/certs.dir/server.csr.pem > > > engine "pkcs11" set. > > > Using configuration from yubihsm2-openssl.conf > > > Login failed > > > Login to token failed, returning NULL... > > > PKCS11_get_private_key returned NULL > > > cannot load CA private key from engine > > > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too > > > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters > > > 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid > > > arguments:p11_slot.c:240: > > > 140735853761408:error:26096080:engine > > > routines:ENGINE_load_private_key:failed loading private > > > key:crypto/engine/eng_pkey.c:78: > > > unable to load CA private key > > > > > > Best Regards > > > //P > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
The error can be workaround by entering PIN = "..." into [pkcs11_section]. pkcs11 engine version is libp11-0.4.9. Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me doing something wrong? On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson wrote: > > Hi, > > I'm trying to understand how to make "openssl ca" prompt for a PKCS#11 > login pin. Version is openssl-1.1.1. > > openssl req works as I would expect, prompting for PIN: > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \ > local-build/bin/openssl \ > req -config yubihsm2-openssl.conf -new \ > -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out > certs.dir/ca.csr.pem > engine "pkcs11" set. > Enter PKCS#11 token PIN for YubiHSM: > > openssl ca I fail to get working, no prompt presented, tried adding > -passin stdin but that has no effect. > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \ > local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform > engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \ > -config yubihsm2-openssl.conf \ > -days 3650 -extensions vpn_server_cert \ > -out server.cert.pem \ > -infiles ../server/certs.dir/server.csr.pem > engine "pkcs11" set. > Using configuration from yubihsm2-openssl.conf > Login failed > Login to token failed, returning NULL... > PKCS11_get_private_key returned NULL > cannot load CA private key from engine > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters > 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid > arguments:p11_slot.c:240: > 140735853761408:error:26096080:engine > routines:ENGINE_load_private_key:failed loading private > key:crypto/engine/eng_pkey.c:78: > unable to load CA private key > > Best Regards > //P -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
Hi, I'm trying to understand how to make "openssl ca" prompt for a PKCS#11 login pin. Version is openssl-1.1.1. openssl req works as I would expect, prompting for PIN: YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \ local-build/bin/openssl \ req -config yubihsm2-openssl.conf -new \ -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out certs.dir/ca.csr.pem engine "pkcs11" set. Enter PKCS#11 token PIN for YubiHSM: openssl ca I fail to get working, no prompt presented, tried adding -passin stdin but that has no effect. YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \ local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \ -config yubihsm2-openssl.conf \ -days 3650 -extensions vpn_server_cert \ -out server.cert.pem \ -infiles ../server/certs.dir/server.csr.pem engine "pkcs11" set. Using configuration from yubihsm2-openssl.conf Login failed Login to token failed, returning NULL... PKCS11_get_private_key returned NULL cannot load CA private key from engine 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid arguments:p11_slot.c:240: 140735853761408:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78: unable to load CA private key Best Regards //P -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl commandline client use
You would be better off with AES-CCM or such for your backup, that gives you the integrity check. i.e. you would be reasonably sure what you decrypt is encrypted with your key. So the fist question would be why even consider AES-CBC? Somewhere in the decision process you ought to go "Is the major goal to support very strange extremely limited legacy embedded environment where library developers claims CBC is the only option?" and if no: don't consider CBC. Since you are using OpenSSL, you clearly does not have any problem that would give you a compelling reason to use CBC. Using CBC in anything new design does not make much sense. - CBC is weak against oracle attacks (online interactions with a decryption oracle) - CBC has no protection against modifications. If decryption succeeds, you don't know if the resulting plaintext originated from However - Your use-case as explained ( openssl enc -aes-256-cbc -k mypass > backup.xb.gz.enc ) might not be a use-case where the AES-CBC vulnerabilities are most dangerous though, if the decryption process is a slow manual process. E.g. Padding oracle attacks against CBC requires on average 128 decryption to crack one byte, and need an online oracle (such as e.g. a backup decryption/restore service) to be executed. With a human entering the decryption key manually for each attempt, you'd expect the human to get suspicious with thousands of decryption requests. But as soon as you want to automate restore functions and remove the human, you might enable oracle style attacks. On Thu, Oct 11, 2018 at 6:45 AM Paul Chubb wrote: > > Hi thanks for the responses. I try not to do crypto for the very reasons you > raise - i simply don't know enough and your (good) pointed questions have > demonstrated that. > > Context: > > We are trying for GDPR and other privacy law compliance. We probably need to > meet GDPR, US requirements, Australian requirements, Japanese requirements > and UK requirements. The data is not hugely critical. It contains names and > exercise metrics. It doesn't contain credit card details or anything above > the level of names. I don't think it contains addresses but probably does > contain names of recognizable organisations which could provide a tuple for > identification purposes if the data was compromised. > > A mysqldump of the db in production at present is around 170Gb however that > is text based and we are using a binary solution based on percola xtrabackup > so the final size should be smaller for the current time. The documentation > on this by the backup software provider is very simplistic and simply pipes > the stream of data through openssl and then gzip: > > mariabackup --user=root --backup --stream=xbstream | gzip | openssl enc > -aes-256-cbc -k mypass > backup.xb.gz.enc > > There are thousands of posts that do similar and in non-crypto circles it is > the accepted way of doing things. That was my starting point. > > I am not using a password but generating keys. The symetric key is generated > by "openssl rand -hex 32" which I have read is suitable. The Nonce or IV is > generated by "openssl rand -hex 16". These values are used once and then > kept for decryption of that file. They in turn are encrypted before storing - > see below. > > The two keys are held in ram while the backup occurs. They are applied to > openssl using the -K and -iv switches. They are then written out to disk. > encrypted with a list of public RSA keys and the original deleted from disk. > I then package it all up and delete the intervening encrypted files leaving > me with an archive with the encrypted backup and several copies of the nonce > and key each encrypted by different people's public keys. > > The backup regime has not been decided as yet. I expect it will be something > like a full backup per week and then either incrementals or differentials on > the other days. I expect that the fulls will be kept for 30 days and the > deltas for 14days. The database backups will sit on a secured server disk > which in turn will be backed up by the hosting provider with whatever process > and rotation they use. > > I would expect that headers in the backup stream would be predictable, > whether they provide a good enough attack surface I don't know. In addition > the clients of course know their data that may also provide an attack > surface. Finally I have included an encrypted file with a known plain text > phrase. Based on your comments, this will probably not get into production > but provides an easy way for testing and debugging to check that things are > encrypted or not. > > The kind of statements that prompted my question was: > https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup > whose comments suggest that openssl should never be used for production > purposes.Their suggestion was GnuPG which isn't suitable for this purpose > because it does password/key
Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate
> trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n) Yes that seems to be aligned with how the intended the path validation algorithm should be applied, i.e. first certificate processed is the cert of the trust anchor. But it could be clearer, and wording "recommended" (lowercase) does seem to imply implementers SHOULD process trust anchor cert rather than MUST process it. " In Section 6.1, the text describes basic path validation. Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths that may be validated using this key." ... " Where a CA distributes self-signed certificates to specify trust anchor information, certificate extensions can be used to specify recommended inputs to path validation. For example, a policy constraints extension could be included in the self-signed certificate to indicate that paths beginning with this trust anchor should be trusted only for the specified policies." > https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3 > Does that address your concerns? I think so! I'll integrate it into my tests and try to do Q/A on the change, see if I can figure out any other edge case. Best Regards //P On Mon, Oct 8, 2018 at 6:15 PM Viktor Dukhovni wrote: > > > On Oct 8, 2018, at 8:47 AM, Peter Magnusson > > wrote: > > > > RFC5280 Certification Path Validation algorithm process from root to > > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4 > > Preparation for Certificate i+1 is expected to occur upon Root > > certificate, i.e. the following should be expected behaviour: > > * max_path_length=n (initialisation) > > * max_path_length=n-1 (first decrement) > > * max_path_length=0 (copied from root certificate constraint) > > * VERIFY(max_path_length>0) error upon preparing transition from i=1 > > (Root) to i=2 (EvilCA). > > Well, strictly speaking, the trust-anchor is not part of the certificate > chain in RFC5280, it is a public key and an issuer name, not a certificate > in the chain. However, when the trust-anchor is in the form of a self-signed > CA certificate, one might take the view that this is a self-issued certificate > to be included in the chain: > > trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n) > > in which case the "path lenth: 0" in the self-issed root CA cert precludes > the root from issuing any subsidiary CAs that can in turn issue further > EE certs. That is perhaps reasonable, so I updated PR #7353 with > a further commit: > > > https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3 > > Does that address your concerns? > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate
Tested mbedtls to see how other code bases handle thus. mbedtls rejects the EvilCA certificate when connecting to openssl s_server (as opposed to openssl c_client -verify that accepts the connection). Verify requested for (Depth 1): cert. version : 3 serial number : 10:00 issuer name : C=SE, ST=Root, L=Root, O=Root, OU=Root, CN=Root subject name : C=SE, ST=EvilCA, L=EvilCA, O=EvilCA, OU=EvilCA, CN=EvilCA issued on: 2018-10-08 08:20:21 expires on: 2028-10-05 08:20:21 signed using : RSA with SHA-256 RSA key size : 4096 bits basic constraints : CA=true, max_pathlen=0 key usage : Key Cert Sign, CRL Sign ! The certificate is not correctly signed by the trusted CA The handshake fails after this error, mbedtls_ssl_handshake returned -9984. On Mon, Oct 8, 2018 at 2:51 PM Peter Magnusson wrote: > > sorry, typo on the verify line, this was what I should have written: > VERIFY(max_path_length>0) error upon preparing transition from i=2 > (EvilCA) to i=2 (EvilServer). > On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson > wrote: > > > > That is not correct behaviour as far as I can understand. > > > > RFC5280 Certification Path Validation algorithm process from root to > > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4 > > Preparation for Certificate i+1 is expected to occur upon Root > > certificate, i.e. the following should be expected behaviour: > > * max_path_length=n (initialisation) > > * max_path_length=n-1 (first decrement) > > * max_path_length=0 (copied from root certificate constraint) > > * VERIFY(max_path_length>0) error upon preparing transition from i=1 > > (Root) to i=2 (EvilCA). > > > > OpenSSL does everything in a slightly different reverse algorithm, but > > should perform the same controls and behaivor as the RFC imho. > > > > And aside from the RFC algorithm checking for this condition, it is > > also analog with the description of the expected behaviour: > > > >The pathLenConstraint field is meaningful only if the cA boolean is > >asserted and the key usage extension, if present, asserts the > >keyCertSign bit (Section 4.2.1.3). In this case, it gives the > >maximum number of non-self-issued intermediate certificates that may > >follow this certificate in a valid certification path. (Note: The > >last certificate in the certification path is not an intermediate > >certificate, and is not included in this limit. Usually, the last > >certificate is an end entity certificate, but it can be a CA > >certificate.) A pathLenConstraint of zero indicates that no non- > >self-issued intermediate CA certificates may follow in a valid > >certification path. Where it appears, the pathLenConstraint field > >MUST be greater than or equal to zero. Where pathLenConstraint does > >not appear, no limit is imposed. > > > > So my understanding is that the OpenSSL algorithm is confused and > > fails to perform a check that is applicable to self-issued > > certificates. The decrement of max_path_length (aka plen++ in OpenSSL > > implementation) should not occur for self issued certificates, but the > > validation of max_path_length>0 (aka plen>(constraint+1)) should > > occur. > > On Mon, Oct 8, 2018 at 1:27 PM J Decker wrote: > > > > > > It was my interpretation that 0 pathlen on the root self signed meant > > > infinite. > > > The pathlen only applies on the certs between root and the leaf (which > > > obviously can be 0, and CA true or not, but bad form to say true I'd > > > imagine.) > > > > > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson > > > wrote: > > >> > > >> One more logic confusion in the OpenSSL Path Length Constraint check. > > >> Any Path Length Constraint set by Root (or any other Self-Issued > > >> Certificate) is ignored. > > >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly > > >> applied to the checker (i.e. the checker and the calculation logic > > >> have been mixed up). > > >> > > >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2 > > >> > > >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic" > > >> Certificate Sign, CRL Sign > > >> X509v3 Basic Constraints: critical > > >> CA:TRUE, pathlen:0 > > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic" > > >> Certific
Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate
sorry, typo on the verify line, this was what I should have written: VERIFY(max_path_length>0) error upon preparing transition from i=2 (EvilCA) to i=2 (EvilServer). On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson wrote: > > That is not correct behaviour as far as I can understand. > > RFC5280 Certification Path Validation algorithm process from root to > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4 > Preparation for Certificate i+1 is expected to occur upon Root > certificate, i.e. the following should be expected behaviour: > * max_path_length=n (initialisation) > * max_path_length=n-1 (first decrement) > * max_path_length=0 (copied from root certificate constraint) > * VERIFY(max_path_length>0) error upon preparing transition from i=1 > (Root) to i=2 (EvilCA). > > OpenSSL does everything in a slightly different reverse algorithm, but > should perform the same controls and behaivor as the RFC imho. > > And aside from the RFC algorithm checking for this condition, it is > also analog with the description of the expected behaviour: > >The pathLenConstraint field is meaningful only if the cA boolean is >asserted and the key usage extension, if present, asserts the >keyCertSign bit (Section 4.2.1.3). In this case, it gives the >maximum number of non-self-issued intermediate certificates that may >follow this certificate in a valid certification path. (Note: The >last certificate in the certification path is not an intermediate >certificate, and is not included in this limit. Usually, the last >certificate is an end entity certificate, but it can be a CA >certificate.) A pathLenConstraint of zero indicates that no non- >self-issued intermediate CA certificates may follow in a valid >certification path. Where it appears, the pathLenConstraint field >MUST be greater than or equal to zero. Where pathLenConstraint does >not appear, no limit is imposed. > > So my understanding is that the OpenSSL algorithm is confused and > fails to perform a check that is applicable to self-issued > certificates. The decrement of max_path_length (aka plen++ in OpenSSL > implementation) should not occur for self issued certificates, but the > validation of max_path_length>0 (aka plen>(constraint+1)) should > occur. > On Mon, Oct 8, 2018 at 1:27 PM J Decker wrote: > > > > It was my interpretation that 0 pathlen on the root self signed meant > > infinite. > > The pathlen only applies on the certs between root and the leaf (which > > obviously can be 0, and CA true or not, but bad form to say true I'd > > imagine.) > > > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson > > wrote: > >> > >> One more logic confusion in the OpenSSL Path Length Constraint check. > >> Any Path Length Constraint set by Root (or any other Self-Issued > >> Certificate) is ignored. > >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly > >> applied to the checker (i.e. the checker and the calculation logic > >> have been mixed up). > >> > >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2 > >> > >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic" > >> Certificate Sign, CRL Sign > >> X509v3 Basic Constraints: critical > >> CA:TRUE, pathlen:0 > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic" > >> Certificate Sign, CRL Sign > >> X509v3 Basic Constraints: critical > >> CA:TRUE, pathlen:0 > >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic" > >> X509v3 extensions: > >> X509v3 Basic Constraints: critical > >> CA:FALSE > >> > >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier" > >> X509v3 extensions: > >> X509v3 Subject Key Identifier: > >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 > >> -- > >> -- > >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 > >> X509v3 Authority Key Identifier: > >> > >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier" > >> X509v3 extensions: > >> X509v3 Subject Key Identifier: > >> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C &g
Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate
That is not correct behaviour as far as I can understand. RFC5280 Certification Path Validation algorithm process from root to leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4 Preparation for Certificate i+1 is expected to occur upon Root certificate, i.e. the following should be expected behaviour: * max_path_length=n (initialisation) * max_path_length=n-1 (first decrement) * max_path_length=0 (copied from root certificate constraint) * VERIFY(max_path_length>0) error upon preparing transition from i=1 (Root) to i=2 (EvilCA). OpenSSL does everything in a slightly different reverse algorithm, but should perform the same controls and behaivor as the RFC imho. And aside from the RFC algorithm checking for this condition, it is also analog with the description of the expected behaviour: The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit (Section 4.2.1.3). In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path. (Note: The last certificate in the certification path is not an intermediate certificate, and is not included in this limit. Usually, the last certificate is an end entity certificate, but it can be a CA certificate.) A pathLenConstraint of zero indicates that no non- self-issued intermediate CA certificates may follow in a valid certification path. Where it appears, the pathLenConstraint field MUST be greater than or equal to zero. Where pathLenConstraint does not appear, no limit is imposed. So my understanding is that the OpenSSL algorithm is confused and fails to perform a check that is applicable to self-issued certificates. The decrement of max_path_length (aka plen++ in OpenSSL implementation) should not occur for self issued certificates, but the validation of max_path_length>0 (aka plen>(constraint+1)) should occur. On Mon, Oct 8, 2018 at 1:27 PM J Decker wrote: > > It was my interpretation that 0 pathlen on the root self signed meant > infinite. > The pathlen only applies on the certs between root and the leaf (which > obviously can be 0, and CA true or not, but bad form to say true I'd imagine.) > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson > wrote: >> >> One more logic confusion in the OpenSSL Path Length Constraint check. >> Any Path Length Constraint set by Root (or any other Self-Issued >> Certificate) is ignored. >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly >> applied to the checker (i.e. the checker and the calculation logic >> have been mixed up). >> >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2 >> >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic" >> Certificate Sign, CRL Sign >> X509v3 Basic Constraints: critical >> CA:TRUE, pathlen:0 >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic" >> Certificate Sign, CRL Sign >> X509v3 Basic Constraints: critical >> CA:TRUE, pathlen:0 >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic" >> X509v3 extensions: >> X509v3 Basic Constraints: critical >> CA:FALSE >> >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier" >> X509v3 extensions: >> X509v3 Subject Key Identifier: >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 >> -- >> -- >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 >> X509v3 Authority Key Identifier: >> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier" >> X509v3 extensions: >> X509v3 Subject Key Identifier: >> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C >> -- >> -- >> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C >> X509v3 Authority Key Identifier: >> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 >> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier" >> TLS Web Server Authentication >> X509v3 Subject Key Identifier: >> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE >> -- >> -- >> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE >>
[openssl-users] Path Length Constraint ignored for Root and any self-issued certificate
One more logic confusion in the OpenSSL Path Length Constraint check. Any Path Length Constraint set by Root (or any other Self-Issued Certificate) is ignored. Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly applied to the checker (i.e. the checker and the calculation logic have been mixed up). https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2 openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic" Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic" Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic" X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier" X509v3 extensions: X509v3 Subject Key Identifier: 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 -- -- 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 X509v3 Authority Key Identifier: keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier" X509v3 extensions: X509v3 Subject Key Identifier: B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C -- -- B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C X509v3 Authority Key Identifier: keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5 openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier" TLS Web Server Authentication X509v3 Subject Key Identifier: 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE -- -- 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE X509v3 Authority Key Identifier: keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile root.pem -untrusted evilca.pem evilserver.pem *** important variables *** *** check_chain_extensions:524 i=0 *** check_chain_extensions:525 plen=0 *** check_chain_extensions:526 x->ex_pathlen=-1 *** if statement components *** *** check_chain_extensions:528 i > 1=0 *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1 *** check_chain_extensions:530 (x->ex_pathlen != -1)=0 *** check_chain_extensions:531 (plen > (x->ex_pathlen + proxy_path_length + 1))=0 *** important variables *** *** check_chain_extensions:524 i=1 *** check_chain_extensions:525 plen=1 *** check_chain_extensions:526 x->ex_pathlen=0 *** if statement components *** *** check_chain_extensions:528 i > 1=0 *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1 *** check_chain_extensions:530 (x->ex_pathlen != -1)=1 *** check_chain_extensions:531 (plen > (x->ex_pathlen + proxy_path_length + 1))=0 *** important variables *** *** check_chain_extensions:524 i=2 *** check_chain_extensions:525 plen=2 *** check_chain_extensions:526 x->ex_pathlen=0 *** if statement components *** *** check_chain_extensions:528 i > 1=1 *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0 *** check_chain_extensions:530 (x->ex_pathlen != -1)=1 *** check_chain_extensions:531 (plen > (x->ex_pathlen + proxy_path_length + 1))=1 evilserver.pem: OK Chain: depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = EvilServer, CN = EvilServer (untrusted) depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN = EvilCA (untrusted) depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0
Thanks, I provided some input regarding off by one calculation of plen still present in the patch. You are very much correct on the definition of self-issued; rfc5280, "A certificate is self-issued if the same DN appears in the subject and issuer fields (the two DNs are the same if they match according to the rules specified in Section 7.1)." Effectively path length constraint is useless for limiting impact of a temporary CA breach, as attacker can just issue an intermediate authority with a DN that matches the definition of self-issued. The feature simply doesn't provide the functionality I presumed it was it core purpose of providing. It was very lucky for me I messed up my DN's so I could learn that, thank you *very* much for your input, that was very useful to be aware of! Best Regards //P On Fri, Oct 5, 2018 at 7:10 AM Viktor Dukhovni wrote: > > > > > On Oct 4, 2018, at 6:25 AM, Viktor Dukhovni > > wrote: > > > > but this corner-case is not correct, the concept of "self-issued" > > only applies to CAs, so for the leaf to be skipped it would have > > the be a self-issued CA. Try the patch below: > > I've simplified the patch in https://github.com/openssl/openssl/pull/7353 > please take a look. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0
Your patch does seem to resolve the test case. II have maximised confusion by generating a CSR with the same textual information for EvilCA as EvilServer. I don't think the chain includes any self signed certificates except the root; 73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 (root, self issued) DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70 issued by 73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6. 17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0 issued by DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70. 1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6 issued by 17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0. Modulus of evilca.pem begins with 00:cd:ba:9f and modulus of evilserver.pem begins with 00:af:83:6f, so they are different even if both have Subject: C=SE, ST=EvilServer, L=EvilServer, O=EvilServer, OU=EvilServer, CN=EvilServer. Funnily enough I don't trigger the edge case on regenerated files with correct Subject information. openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier" X509v3 extensions: X509v3 Subject Key Identifier: 73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 -- -- 73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 X509v3 Authority Key Identifier: keyid:73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 openssl x509 -text -in intermediate.pem | egrep -a1 "X509v3 .* Key Identifier" X509v3 extensions: X509v3 Subject Key Identifier: DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70 -- -- DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70 X509v3 Authority Key Identifier: keyid:73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier" X509v3 extensions: X509v3 Subject Key Identifier: 17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0 -- -- 17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0 X509v3 Authority Key Identifier: keyid:DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70 openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier" TLS Web Server Authentication X509v3 Subject Key Identifier: 1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6 -- -- 1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6 X509v3 Authority Key Identifier: keyid:17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0 On Thu, Oct 4, 2018 at 12:26 PM Viktor Dukhovni wrote: > > On Wed, Oct 03, 2018 at 07:16:51PM +0200, Peter Magnusson wrote: > > > The following test case attempts to validates evilserver.pem, issued > > by evilca.pem. > > More specifically, we see that in this test the leaf server certificate > has the same subject and issuer, so EXFLAG_SI is set for that > certificate, and it did not count in the path length: > > $ /usr/local/bin/openssl verify -show_chain -verbose -trusted root.pem > -untrusted untrusted.pem evilserver.pem > evilserver.pem: OK > Chain: > depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = > EvilServer, CN = EvilServer (untrusted) > depth=1: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = > EvilServer, CN = EvilServer (untrusted) > depth=2: C = SE, ST = Intermediate, O = Intermediate, OU = Intermediate, > CN = Intermediate (untrusted) > depth=3: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root > > but this corner-case is not correct, the concept of "self-issued" > only applies to CAs, so for the leaf to be skipped it would have > the be a self-issued CA. Try the patch below: > > -- > Viktor. > > diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c > index 3a60d412da..77ca325d54 100644 > --- a/crypto/x509/x509_vfy.c > +++ b/crypto/x509/x509_vfy.c > @@ -445,6 +445,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx) > int i, must_be_ca, plen = 0; > X509 *x; > int proxy_path_length = 0; > +int is_ca; > int purpose; > int allow_proxy_certs; > int num = sk_X509_num(ctx->chain); > @@ -484,7 +485,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx) > X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED)) > return 0; > } > -ret = X509_check_ca(x); > +ret = is_ca = X509_check_ca(x); > switch (must_be_ca) { > case -1: > if ((ctx->param->flags & X509_V_FLAG_X509_STRICT) > @@
Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0
Is this expected? (plen > (x->ex_pathlen + proxy_path_length + 1)) evaluates to false (constraint not violated) when checking constraint 0 against plen=1 (constraint violated as far as I can understand?). Doesn't make much sense to me. Is there something I haven't understood about how the constraint is supposed to work? *** important variables *** *** check_chain_extensions:523 i=0 *** check_chain_extensions:524 plen=0 *** check_chain_extensions:525 x->ex_pathlen=-1 *** if statement components *** *** check_chain_extensions:527 i > 1=0 *** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=0 *** check_chain_extensions:529 (x->ex_pathlen != -1)=0 *** check_chain_extensions:530 (plen > (x->ex_pathlen + proxy_path_length + 1))=0 *** important variables *** *** check_chain_extensions:523 i=1 *** check_chain_extensions:524 plen=0 *** check_chain_extensions:525 x->ex_pathlen=-1 *** if statement components *** *** check_chain_extensions:527 i > 1=0 *** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=1 *** check_chain_extensions:529 (x->ex_pathlen != -1)=0 *** check_chain_extensions:530 (plen > (x->ex_pathlen + proxy_path_length + 1))=0 *** important variables *** *** check_chain_extensions:523 i=2 *** check_chain_extensions:524 plen=1 *** check_chain_extensions:525 x->ex_pathlen=0 *** if statement components *** *** check_chain_extensions:527 i > 1=1 *** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=1 *** check_chain_extensions:529 (x->ex_pathlen != -1)=1 *** check_chain_extensions:530 (plen > (x->ex_pathlen + proxy_path_length + 1))=0 *** important variables *** *** check_chain_extensions:523 i=3 *** check_chain_extensions:524 plen=2 *** check_chain_extensions:525 x->ex_pathlen=1 *** if statement components *** *** check_chain_extensions:527 i > 1=1 *** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=0 *** check_chain_extensions:529 (x->ex_pathlen != -1)=1 *** check_chain_extensions:530 (plen > (x->ex_pathlen + proxy_path_length + 1))=0 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0
The following test case attempts to validates evilserver.pem, issued by evilca.pem. evil*.pem is violating: 1/ pathlen=0 constraint of the compromised intermediate.pem (issuer of evilserver.pem) 2/ pathlen=1 constraint of the non-compromised root-ca.pem (issuer of intermediate.pem) The particular example execution is from Mac (LibreSSL) but same behaviour observed with e.g. homebrew as well. https://github.com/blaufish/openssl-pathlen openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic" Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:1 openssl x509 -text -in intermediate.pem | grep -a1 "X509v3 Basic" Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic" X509v3 Basic Constraints: critical CA:TRUE openssl verify -verbose -CAfile root.pem -untrusted untrusted.pem evilserver.pem evilserver.pem: OK On Wed, Oct 3, 2018 at 4:51 PM Viktor Dukhovni wrote: > > On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Magnusson wrote: > > > $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem > > evil.pem > > evil.pem: OK > > This is expected to work when intermediate.pem has pathlen 0, because > you're verifying "evil.pem" as a *leaf* certificate, its CA:true > is irrelevant when it is the last (leaf) certificate in the chain. > > An actually unexpected result would be: > > $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem > -untrusted evil.pem badee.pem > badee.pem: OK > > where badee.pem is signed by evil.pem. The path length constraint > is not a constraint against issuing EE certs with CA:true, it only > constraints the number additional intermediate (non-self-issued) > CAs in a valid path. In your example that number is zero. > >https://tools.ietf.org/html/rfc5280#section-4.2.1.9 > >The pathLenConstraint field is meaningful only if the cA boolean is >asserted and the key usage extension, if present, asserts the >keyCertSign bit (Section 4.2.1.3). In this case, it gives the >maximum number of non-self-issued intermediate certificates that may >follow this certificate in a valid certification path. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0
Hi, It is my understanding "openssl verify" should raise X509_V_ERR_PATH_LENGTH_EXCEEDED should be raised if pathlen=0 intermediate issues a new CA, but that does not seem to occur when I test with a couple pf openssl versions. I am not sure due to limited understanding of the code, but I am wonder if there isn't an off-by-one or out-of-order increment error in x509_vfy.c in this check: (plen > (x->ex_pathlen + proxy_path_length + 1))). if plen=1 and x->ex_pathlen=0, the check would become 1>1 (false) while it was expected to raise an error? openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem evil.pem evil.pem: OK openssl x509 -text -in root.pem | egrep -a1 X509v3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5 -- -- A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5 X509v3 Authority Key Identifier: keyid:A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5 -- -- X509v3 Key Usage: Certificate Sign, CRL Sign -- -- Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:1 openssl x509 -text -in intermediate.pem | egrep -a1 X509v3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD -- -- B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD X509v3 Authority Key Identifier: keyid:A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5 -- -- X509v3 Key Usage: Certificate Sign, CRL Sign -- -- Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 openssl x509 -text -in evil.pem | egrep -a1 X509v3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 81:3A:5A:BD:9E:6C:08:0F:C7:6A:31:A2:0D:0F:2A:02:62:BE:63:12 -- -- 81:3A:5A:BD:9E:6C:08:0F:C7:6A:31:A2:0D:0F:2A:02:62:BE:63:12 X509v3 Authority Key Identifier: keyid:B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD -- -- X509v3 Basic Constraints: critical CA:TRUE -- -- CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] building openssl 1.1.1 using CrystaX NDK 10.3.2 (Android)
c aes-armv4.S bsaes-armv7.S aesv8-armx.S", aes_obj => "aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o", apps_aux_src => "", apps_init_src => "", apps_obj => "", bf_asm_src => "bf_enc.c", bf_obj => "bf_enc.o", bin_cflags => "-pie", bn_asm_src => "bn_asm.c armv4-mont.S armv4-gf2m.S", bn_obj => "bn_asm.o armv4-mont.o armv4-gf2m.o", bn_ops => "BN_LLONG RC4_CHAR", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cast_asm_src => "c_enc.c", cast_obj => "c_enc.o", cflags => "-pthread -mandroid --sysroot=\$(ANDROID_NDK)/platforms/android-16/arch-arm", chacha_asm_src => "chacha-armv4.S", chacha_obj => "chacha-armv4.o", cmll_asm_src => "camellia.c cmll_misc.c cmll_cbc.c", cmll_obj => "camellia.o cmll_misc.o cmll_cbc.o", cppflags => "", cpuid_asm_src => "armcap.c armv4cpuid.S", cpuid_obj => "armcap.o armv4cpuid.o", cxxflags => "-std=c++11 -pthread -mandroid --sysroot=\$(ANDROID_NDK)/platforms/android-16/arch-arm", defines => [ ], des_asm_src => "des_enc.c fcrypt_b.c", des_obj => "des_enc.o fcrypt_b.o", disable => [ ], dso_extension => ".so", dso_scheme => "dlfcn", ec_asm_src => "ecp_nistz256.c ecp_nistz256-armv4.S", ec_obj => "ecp_nistz256.o ecp_nistz256-armv4.o", enable => [ ], ex_libs => "-ldl -pthread", exe_extension => "", includes => [ ], keccak1600_asm_src => "keccak1600-armv4.S", keccak1600_obj => "keccak1600-armv4.o", lflags => "", lib_cflags => "", lib_cppflags => "-DOPENSSL_USE_NODELETE", lib_defines => [ ], md5_asm_src => "", md5_obj => "", modes_asm_src => "ghash-armv4.S ghashv8-armx.S", modes_obj => "ghash-armv4.o ghashv8-armx.o", module_cflags => "-fPIC", module_cxxflags => "", module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", padlock_asm_src => "", padlock_obj => "", perlasm_scheme => "void", poly1305_asm_src => "poly1305-armv4.S", poly1305_obj => "poly1305-armv4.o", rc4_asm_src => "rc4_enc.c rc4_skey.c", rc4_obj => "rc4_enc.o rc4_skey.o", rc5_asm_src => "rc5_enc.c", rc5_obj => "rc5_enc.o", rmd160_asm_src => "", rmd160_obj => "", sha1_asm_src => "sha1-armv4-large.S sha256-armv4.S sha512-armv4.S", sha1_obj => "sha1-armv4-large.o sha256-armv4.o sha512-armv4.o", shared_cflag => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", shared_extension_simple => ".so", shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "linux-shared", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", uplink_aux_src => "", uplink_obj => "", wp_asm_src => "wp_block.c", wp_obj => "wp_block.o", Recorded environment: AR = BUILDFILE = CC = CROSS_COMPILE = - CXX = ccache arm-linux-androideabi-g++ -DANDROID -mandroid -fomit-frame-pointer --sysroot /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm -I/home/peter/quick/OSGeo4A/stage/armeabi-v7a/include -L/opt/crystax-ndk-10.3.2/sources/crystax/libs/armeabi-v7a -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb -isystem /opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include HASHBANGPERL = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = arm-linux-androideabi-ranlib RC = WINDRES = __CNF_CFLAGS = -march=armv7-a __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = -march=armv7-a __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = arm-linux-androideabi-ar ARFLAGS = r CC = arm-linux-a
Re: [openssl-users] Cant seem to get prompt no to work
On 08/18/2017 07:16 PM, Dr. Stephen Henson wrote: > On Thu, Aug 17, 2017, Robert Moskowitz wrote: > >> In the [ ca ] section I have: >> >> prompt = no >> >> If I leave the = out I get an error, so I am assuming I got the >> format of this right. >> >> Then I have >> >> [ req ] >> distinguished_name = req_distinguished_name >> >> [ req_distinguished_name ] >> countryName = $ENV::countryName >> stateOrProvinceName = $ENV::stateOrProvinceName >> >> In a terminal window I run: >> >> export countryName=US >> export stateOrProvinceName=MI What about: [ req_distinguished_name ] countryName = "Country Nmae (e.g. FR)" countryName_value = $ENV::countryName stateOrProvinceName = "State or Province" stateOrProvinceName_value = $ENV::stateOrProvinceName -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] French Declaration
Two points: - you use function xyz of openssl (is the implementation safe?) - the purpose of using this in your application is "saving peanuts". what are peanuts? /P On 12/01/2016 08:29 PM, Brian Jost wrote: Ok thanks, so there isn't a generic declaration that applications using openssl standard encryption like GCM can use? Each application will have to get self declared? On Thu, Dec 1, 2016 at 12:12 PM, Peter Sylvester Edelweb <peter.sylves...@edelweb.fr<mailto:peter.sylves...@edelweb.fr>> wrote: Hi There are news since about a year. https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/ There is a downloadable editable PDF to prepare the declaration. Anyway, you normally do not declare all functionality of the openssl library if you use it in a product. It may be as simple as "to hash passwords we use the SHAnnn functions as implemented by openssl". I used to make such declarations about 15 years ago. Peter -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] French Declaration
Hi There are news since about a year. https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/ There is a downloadable editable PDF to prepare the declaration. Anyway, you normally do not declare all functionality of the openssl library if you use it in a product. It may be as simple as "to hash passwords we use the SHAnnn functions as implemented by openssl". I used to make such declarations about 15 years ago. Peter -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OCSP verification issue
I recently ran into a bug with verification of OCSP responses that appears to be in all versions of OpenSSL (including current 1.1.0 builds). RFC 6960 and its predecessor 2560 allow that the response may be signed by the key for "the CA who issued the certificate in question” (section 2.2). In this case it should not be necessary to include any certs in the basicResponse, as the signature can be validated using the public key used to validate the certificate whose status is being checked. While this is contemplated by the RFCs, OpenSSL fails in certain cases if no certificates are provided in the response. If there are at least two intermediate CAs in the certificate chain between a trust anchor and end entity certificate, then OCSP_basic_verify will return a certificate verify error. The code below reproduces the failure and demonstrates that reducing the path length from anchor to end entity certificate resolves the issue as does adding a certificate from the trust anchor to the first CA to the response. I think the correct behaviour would be to check if the issuer of the certificate matches the signer of the OCSP response and, if so, simply skip the X509_verify_cert check. Thanks, Peter #!/usr/bin/env ruby # Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved. # # Licensed under the OpenSSL license (the "License"). You may not use # this file except in compliance with the License. You can obtain a copy # in the file LICENSE in the source distribution or at # https://www.openssl.org/source/license.html require 'openssl' require 'base64' require 'open3' # Ruby has no to_text method for OCSP responses, so shell out def ocsp_to_text(ocsp_der) # Figure out if our base64 uses -D or -d to decode %x/echo | base64 -D/ if $? == 0 dparam="-D" else dparam="-d" end out = "" Open3::popen2("/bin/bash -t") do |i, o, t| i.puts("openssl ocsp -noverify -text -respin <(echo #{Base64.strict_encode64(ocsp_der)} | base64 #{dparam})") o.each{|l|out += l} end out end # Set up Names and Keys for all the certs nodes = { :root => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["O", "Beyond Hypersecure Inc", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "Beyond Hypersecure Root CA", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048) }, :ca1 => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["O", "Beyond Hypersecure Inc", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "Beyond Hypersecure Partner CA", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048) }, :ca2 => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["O", "HyperCyberHost LLC", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "HyperCyberHost Server CA", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048) }, :ee => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "localdemo.sslmap.com", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048), :sans => "DNS:localdemo.sslmap.com" } } # Generate all the certs root_cert = OpenSSL::X509::Certificate.new root_cert.version = 0x2 root_cert.serial = 0x0 root_cert.not_before = Time.new(2004,01,01,00,00,01) root_cert.not_after = Time.new(2028,12,31,23,59,59) root_cert.subject = nodes[:root][:name] root_cert.issuer = root_cert.subject root_cert.public_key = nodes[:root][:key] ef = OpenSSL::X509::ExtensionFactory.new ef.subject_certificate = root_cert ef.issuer_certificate = root_cert root_cert.add_extension(ef.create_extension("subjectKeyIdentifier", "hash", false)) root_cert.add_extension(ef.create_extension("basicConstraints", "CA:TRUE", true)) root_cert.add_extension(ef.create_extension("keyUsage","digitalSignature, keyCertSign, cRLSign", true)) root_cert.sign(nodes[:root][:key], OpenSSL::Digest::SHA256.new) puts root_cert.to_text puts root_cert.to_pem ca1_cert = OpenSSL::X509::Certificate.new ca1_cert.version = 0x2 ca1_cert.serial = 0xa ca1_cert.not_before = Time.new(2011,01,01,00,00,01) ca1_cert.not_after = Time.new(2020,12,31,23,59,59) ca1_cert.subject = nodes[:ca1][:name] ca1_cert.issuer = root_cert.subject ca1_cert.public_key = nodes[:ca1][:key] ef = OpenSSL::X509::ExtensionFactory.new ef.config = OpenSSL::Config.parse(' [polsect] policyIdentifier = 2.5.29.32.0 CPS.1="http://beyondhypersecure.example.
Re: [openssl-users] Building 1.0.2g with
Jakob Bohmwrites: > > In 1.0.2 and later, most of the files in ${BUILD_DIR}/include/openssl > are supposed to be copies/symlinks to file of the same name elsewhere > in the OpenSSL source, for instance the ones you mentions should be > links to files in subdirectories under ${BUILD_DIR}/crypt. > > However in your case, I suspect the following sequence of events: > > 1. configure or make depend sees that you have disabled some ciphers >and don't link header files for those ciphers. > > 2. Other parts of the OpenSSL source code blindly include those header >files because they used to be present in ${BUILD_DIR}/include/openssl >even when disabled, omitting them only (if at all) in the installed >files under ${INSTALL_DIR}/include/openssl > > If this theory holds, this would be a bug in the 1.0.2 tree, either > in the build scripts or in the source files that include headers for > disabled ciphers, whichever fix creates the smallest/simplest patch > should be applied. > > Hi, I am seeing the same problem with 0.9.8zh. config with no-idea and the symlink to the idea.h header file is not created. This breaks the compile in multiple places in crypto. make depend does not create the link when no-idea is configured. We are building openssl inside a customised build environment so I simply create the symlink after config is run and prior to running the compile. Just my pennies worth cheers pete pete hilton also at:- saru...@ruvolo-hilton.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format
Hi Wim, I'll give this a shot, thank you for the suggestion! -Peter On Wed, Nov 11, 2015 at 5:05 PM, Wim Lewis <w...@omnigroup.com> wrote: > > On Nov 9, 2015, at 3:46 PM, Peter P. <p.pan48...@gmail.com> wrote: > > I'm writing an application using Openssl 1.0.2d where I am trying to > take a DER encoded unsigned CSR and read it into an X509_REQ data structure > via the d2i_X509_REQ_bio() function. This function errors out during when I > attempt to read in my unsigned CSR and I would like to know if there is any > other way to read in an unsigned CSR into an X509_REQ data structure. > > A CSR (from PKCS#10 / RFC2986) has the structure: > >SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING } > > where the actual request is the CertificationRequestInfo, and the > signature is composed of the AlgorithmIdentifier + BIT STRING. > > Are you trying to just read in a bare CertificationRequestInfo structure? > I suspect you can do that with a call like > > ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req) > > which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ > replaced by X509_REQ_INFO. I haven't tried it, though. > > (Whether it's a *good idea* to pass bare CSR info structs around is > another question but I'll leave that up to you.) > > > Wim. > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format
Hi Dr. Henson, Thank you for your reply. To work around this issue in my application, I have considered attempting to re-sign an already signed CSR. Is this possible with OpenSSL? Thank you again, Peter On Tue, Nov 10, 2015 at 9:18 AM, Dr. Stephen Henson <st...@openssl.org> wrote: > On Mon, Nov 09, 2015, Peter P. wrote: > > > Hi, > > I'm writing an application using Openssl 1.0.2d where I am trying to > take a > > DER encoded unsigned CSR and read it into an X509_REQ data structure via > > the d2i_X509_REQ_bio() function. This function errors out during when I > > attempt to read in my unsigned CSR and I would like to know if there is > any > > other way to read in an unsigned CSR into an X509_REQ data structure. > > > > The signature on a CSR is mandatory so if it is not present it isn't a > valid > CSR structure any more: that will cause the parser to reject it. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format
Hi, I'm writing an application using Openssl 1.0.2d where I am trying to take a DER encoded unsigned CSR and read it into an X509_REQ data structure via the d2i_X509_REQ_bio() function. This function errors out during when I attempt to read in my unsigned CSR and I would like to know if there is any other way to read in an unsigned CSR into an X509_REQ data structure. Thank you, Peter ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] READ error during tape restore via OpenSSL on AIX
Hello OpenSSL community, We are running OpenSSL on IBM AIX version 7.1 on an IBM Power8 server. The OpenSSL versions installed are as follows: openssh.base.client 6.0.0.6103 COMMIT COMPLETE 06/25/14 17:46:58 openssh.base.server 6.0.0.6103 COMMIT COMPLETE 06/25/14 17:46:58 openssl.base 1.0.1.510 COMMIT COMPLETE 09/23/14 15:49:29 When backing up files to tape with no encryption using the AIX backup command, we are able to restore the files from tape using the AIX restore command, with no issue. When backing up files to tape with symmetric OpenSSL encryption (for instance blowfish, aes-128-cbc, aes-256-cbc, with either a password or a key file) the files back up to tape without error. But when restored from tape, we consistently receive the following error messages during the restore: 804401144:error:0200B005:system library:fread:I/O error:bss_file.c:245: 804401144:error:20082002:BIO routines:FILE_READ:system lib:bss_file.c:246: One of the files backed up and restored is a database file (Intersystems Cache) and the restored database passes an integrity check after each restore. The restored text files in the target directory come up with no differences when using diff to compare them to the original files in the source directory. So, we aren't seeing any issues with the integrity of the restored files. But why are the two error messages showing up consistently? Here's our backup command, this time using the aes-256-cbc encryption algorithm and the password shown: find . -print | backup -ivUf - | openssl enc -aes-256-cbc -k abc123 -out /dev/rmt0.1 And here's the restore command and the result: openssl enc -d -aes-256-cbc -k abc123 -in /dev/rmt0.1 | restore -xvqf - IBM8_SYS2(/store/abcalt)$ bc -k abc123 -in /dev/rmt0.1 | restore -xvqf - x0 . x974127104 ./CACHE.DAT 804401144:error:0200B005:system library:fread:I/O error:bss_file.c:245: 804401144:error:20082002:BIO routines:FILE_READ:system lib:bss_file.c:246: x40904 ./RMS x0 ./stream IBM8_SYS2(/store/abcalt)$ Those two exact 804401144 error messages show up consistently during every tape restore. We have tried specifying the block size on the backup and restore but it makes no difference. It should be noted that when we use the backup and restore commands with OpenSSL encryption and no tape drive, but backing up to a different directory and restoring from there, there are no errors during the restore. The errors only happen when restoring from tape. Any thoughts you have on this are appreciated. Peter M Klee System Analyst Fiserv DataSafe Fiserv Credit Union Solutions 800-523-7282 x 2376 ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] Remove Anchor
Hi All Please let me know if I am posting to the correct list. I set up a reverse proxy for my website using nginx and I had to export the certificate from my web server to put on the proxy. On windows I exported the certs to a .pfx file. On my Unix box, I used the command below to export all the certs to a file. Then I manually removed the private key. *openssl pkcs12 -in file_name.pfx -out outputfile.txt –nodes* Afterwards when I ran a test against it using ssllabs it said that my cert contained an anchor. Does anyone know how to remove this anchor and leave only the necessary certs for my proxy to use? Regards ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [SPAM?] Re : 2 Server certificates
https://www.openssl.org/docs/ssl/SSL_load_client_CA_file.html Load names of CAs from file and use it as a client CA list: SSL_CTX *ctx; STACK_OF(X509_NAME) *cert_names; ... cert_names = SSL_load_client_CA_file(/path/to/CAfile.pem); if (cert_names != NULL) SSL_CTX_set_client_CA_list(ctx, cert_names); else error_handling(); The PKI used for a server certificate is not the same as the one used for client certficates. - a server has a certificate (issued by whatever PKI) - a server can request that a client presents a certificate in order to do so, the protocol requires to send a list of issuers (of client certificats). There is no relation between client certs and the server cert. On 06/13/2014 12:15 PM, nicolas@free.fr wrote: Hi, the fact is a server can only send a single certificate, however this one can be signed by multiple CAs on the other side, a client have (in general) a list of trusted CAs, not a single one so there are two options : - either each client knows the two CAs, then the server can send a certificate signed by any of them - or each client knows only about its own CA, then the server must send a certificate signed by both CAs (note that this is symmetrical, the server verify client certificate the same way) I've never heard about a server with multiple certificates, at least not with SSL/TLS protocols... concerning the list of trusted CAs sent by the server to the client, it comes from the fact that a client can have multiple certificates, for different servers that can use their own CA so it allows a client to choose the good certificate to send to a specific server concerning the server, if it's in public access it uses a certificate issued by a well-known CA (for example one included in your browser) if it's private, it can use its own CA or even a self-signed certificate, and the client has to recover the trusted certificates by itself (this happens the first time you connect to a SSH server for which you have no certificate, or on some websites) hope I made it clear good luck! - Mail d'origine - De: Hafedh TRIMECHE hafedh.trime...@gmail.com À: openssl-users@openssl.org Envoyé: Fri, 13 Jun 2014 10:22:46 +0200 (CEST) Objet: Re: Re : Re: Re : Re: 2 Server certificates Hi Nicolas, pit-ca issued another certificate to a client wanting to connect to the same server identified by secure.payerspot.com. I'm looking for a solution allowing two clients to connect to the same server using certificates issued by different CAs. In this case the client forces the server verification by requesting its certificate. So the two server certificates must be sent to each client . Cetificate chain1 (issued by CA1) 0 s: i: BEGIN CERTIFICATE- -END CERTIFICATE- Cetificate chain2 (issued by CA2) 0 s: i: BEGIN CERTIFICATE- -END CERTIFICATE- Can two certificates be presented to a client which will identify the chained certificate to be verified ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/2-Server-certificates-tp50872p50937.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Upgrade Breakage of Perl Script: RH recent
Thanks Dave, I have approached the server operator about the security shortcomings that you pointed out. In the interim I used your suggestion and altered the cipher list to SSL_cipher_list DEFAULT:!ECDH. This has sorted the problem. I am very grateful for your assistance. Peter. On 21 December 2013 08:08, Dave Thompson dthomp...@prinpay.com wrote: I don’t use Fedora and track its versions, but assuming those are recent RedHat including Fedora recently enabled ECC in its openssl packages after years of excluding it over concerns about Certicom’s patent. That increases the number of cipher suites in the Client Hello message and also adds two extensions (although fairly small for RH) which makes the Hello message bigger, and some servers are known to hang or otherwise fail when the Hello message is bigger than used to be “normal” a decade ago. Apparently api.tab.com.au:443 is such; tested with s_client 255 hangs. (In a 404 it claims to be “WebLogic Server”, which I don’t know about.) I also observe this server does not implement 5746 (secure renegotiation) and will negotiate only TLSv1(.0) and 4 akRSA suites (RC4, 3DES, both AES) suggesting it is rather old. If you can’t get the server operator(s) to fix their server, you need to get openssl as used by perl to send a shorter ClientHello. The most straightforward way is to reduce the set of suites offered, especially since the server implements only 4. According to perldoc for the best perl I have (5.6.1 ActivePerl for Windows) but not tested, LWP::UserAgent can take a hash ssl_opts which apparently are passed (eventually) to openssl. Just making SSL_cipher_list DEFAULT:!ECDH should reduce the cipher list enough, although you might want even more restrictive settings for other reasons, like in general you should always prohibit “export” and “LOW” ciphers which have been broken for years. Alternatively it looks like you can set SSL_version to exclude TLSv12 or just force TLSv1; that excludes a bunch of ciphers and also the sigalgs extension, which should make Hello short enough. *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Peter Abbott *Sent:* Thursday, December 19, 2013 17:29 *To:* openssl-users@openssl.org *Subject:* *** Spam *** Upgrade Breakage of Perl Script Hi, I have a simple perl script which supplies a username and account password to a server. The server in turn returns a password token for further operations. The script does not specifically use openssl but the perl modules LWP::UserAgent and or HTTP::Request must do. The script worked perfectly up to openssl version 1.0.1e-4.fc19.x86_64. Further upgrades to 1.0.1e-28.fc19 and 1.0.1e30.fc19 just hang somewhere at the handshake stage. I am only a novice and have a limited understanding of what is going on. Part of the script is as follows: #!/usr/bin/perl -w use strict; use LWP::UserAgent; use HTTP::Request; my $message = '?xml version=1.0 encoding=utf-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ser=http://service.thirdparty.api.neo.tabcorp.com.au/; soapenv:Header/ soapenv:Body ser:authenticateAccount apiMeta deviceId111/deviceId jurisdictionId2/jurisdictionId requestChannel1/requestChannel usernamePasswordToken/usernamePasswordToken /apiMeta authRequest accountIdxx/accountId accountPassword/accountPassword /authRequest /ser:authenticateAccount /soapenv:Body /soapenv:Envelope'; my $keyn; my $userAgent = LWP::UserAgent-new(); my $request = HTTP::Request-new(POST = ' https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate'); $request-header(SOAPAction = ' http://service.thirdparty.api.neo.tabcorp.com.au/;'); $request-content($message); $request-content_type(text/xml; charset=utf-8); my $response = $userAgent-request($request); if($response-code == 200) { print $response-as_string; } else { print zs } Can anyone shed some light on what is happening here or what I can do to remedy the problem? Thanks, Peter.
Upgrade Breakage of Perl Script
Hi, I have a simple perl script which supplies a username and account password to a server. The server in turn returns a password token for further operations. The script does not specifically use openssl but the perl modules LWP::UserAgent and or HTTP::Request must do. The script worked perfectly up to openssl version 1.0.1e-4.fc19.x86_64. Further upgrades to 1.0.1e-28.fc19 and 1.0.1e30.fc19 just hang somewhere at the handshake stage. I am only a novice and have a limited understanding of what is going on. Part of the script is as follows: #!/usr/bin/perl -w use strict; use LWP::UserAgent; use HTTP::Request; my $message = '?xml version=1.0 encoding=utf-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ser=http://service.thirdparty.api.neo.tabcorp.com.au/; soapenv:Header/ soapenv:Body ser:authenticateAccount apiMeta deviceId111/deviceId jurisdictionId2/jurisdictionId requestChannel1/requestChannel usernamePasswordToken/usernamePasswordToken /apiMeta authRequest accountIdxx/accountId accountPassword/accountPassword /authRequest /ser:authenticateAccount /soapenv:Body /soapenv:Envelope'; my $keyn; my $userAgent = LWP::UserAgent-new(); my $request = HTTP::Request-new(POST = ' https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate'); $request-header(SOAPAction = ' http://service.thirdparty.api.neo.tabcorp.com.au/;'); $request-content($message); $request-content_type(text/xml; charset=utf-8); my $response = $userAgent-request($request); if($response-code == 200) { print $response-as_string; } else { print zs } Can anyone shed some light on what is happening here or what I can do to remedy the problem? Thanks, Peter.
Re: Certificate extensions
On 09/18/2013 09:53 AM, Eisenacher, Patrick wrote: -Please also note that adding extensions to a certificate request usually doesn't make any sense, as those get added to the certificate solely by the certificate issuer's grace. hi, I seem to disagree, well, usually saves you :-) Setting your email address or a server name into the subjectaltname, how do you do this otherwise? setting commonname for the server, ok, setting an email attribute that will them be copied by the CA (and the email removed because it is depracated)? Setting ALL extensions makes a lot of sense, IMO a CA should not add and modify thngs, a CA should *validate* them. The requester indicates what should be in the cert. The current practice by some registrars to add example.org as another name when you have ordered www.example.com etc may be nice for some people, but annoying for others, at best a surprise when policy and practice documents do not even mention these behaviours. Peter Sylvester __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CA hierarchy / pathlen:0
On 08/22/2013 01:29 PM, Peter1234 wrote: Hi Walter, I started with release 0.9.8h and just updated to release 1.0.1e (both on MS Windows). The update to release 1.0.1e didn't change anything unless that the new release does not redirect certificates converted from PEM format to text format into specified file: openssl x509 -in Root_Key_SCert.pem -out Root_Key_SCert.txt -text (text is displayed on screen but not redirected to file, worked with release 0.9.8h) Peter Verification of pathlen is for relying parties. If you own the key of a CA (the quotes are intended), you can sign whatever structure you want. Openssl just uses a ca certficate as a helper to avoid copying its name and some other things. You can use the raw asn1 encoder to create very funny things. No control, nothing, it works as intended. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify callback and sending of the client certificate
On 08/09/2013 11:17 AM, Florian Weimer wrote: Qt installs a verification callback like this |// Register a custom callback to get all verification errors. |X509_STORE_set_verify_cb_func(ctx-cert_store, q_X509Callback); It is not recommended to access to members in the way above, but rather: X509_STORE_set_verify_cb_func(SSL_CTX_get_store(ctx), q_X509Callback); /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about intermediate certificate chain
Please note that s_client is used for debugging connections not certs and might connect EVEN IF the server certificate is not good. http://www.openssl.org/docs/apps/s_client.html#item__verify Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure. For checking your certificate chains I recommend OpenSSL's verify command. http://www.openssl.org/docs/apps/verify.html P On 22 May 2013 03:06, Somesh Chakrabarti itsmesom...@gmail.com wrote: In your s_client command, you still need to include the -CAfile parameter and point it to just the self-signed Root certificate. Your server is sending the intermediates but the client is not able to verify the chain up to a Root. You may want to edit cacerts.pem to include only the Root certificate and try again. On Tue, May 21, 2013 at 5:50 PM, Jorge Ventura jorge.araujo.vent...@gmail.com wrote: That is what I have when I don't include the intermediate in the command: openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts verify depth is 5 CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify error:num=27:certificate not trusted verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify error:num=21:unable to verify the first certificate verify return:1 And this one when I include the two intermediate at cacerts.pem. openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile cacerts.pem -showcerts verify depth is 5 CONNECTED(0003) depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify return:1 depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify return:1 --- Certificate chain 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA On Tue, May 21, 2013 at 7:26 PM, Wim Lewis w...@omnigroup.com wrote: On 21 May 2013, at 5:02 PM, Jorge Ventura wrote: Because the client trust the connection when I inform the intermediate, I suppose the server is not sending the intermediate, only the first certificate in the chain and in this case the command fail. That is a reasonable conclusion. You can check for sure using the -showcerts option to openssl s_client. __ 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Cipher sorting: ssl_cipher_apply_rule never processes list with one member?
Hi, while debugging another thing I discovered what I think is a bug in the CIPHER list handling. Can someone please confirm or disprove that this is a bug? OpenSSL version 1.0.1c. In function ssl_cipher_apply_rule the break criteria (curr == last) is strange. I arrive here with only ONE member in my list, so head == tail. ssl_ciph.c: 956 954: for (;;) 955: { 956: if ((curr == NULL) || (curr == last)) break; If it breaks on (curr == last), then a list with only one member will not be processed at all. I think the check if (curr == last) break; should be in the end of the for -loop instead? best regards Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl s_server client verification
On 22 March 2013 00:19, barcaroller barcarol...@gmail.com wrote: When the openssl s_server program is unable to verify a client certificate, it prints out the following error message: verify error:num=21:unable to verify the first certificate verify return:1 but then continues running as if nothing happened. Shouldn't the program stop immediately? It is a intentional feature. But I think the s_server's documentation is missing an important thing mentioned for s_client. http://www.openssl.org/docs/apps/s_client.html#item__verify -verify depth The verify depth to use. This specifies the maximum length of the server certificate chain and turns on server certificate verification. Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. *As a side effect the connection will never fail due to a server certificate verify failure*. P
Re: 0.9.8 vs 1.0.x
We've found that upstream-tracker.org was a good place to start. Unfortunately, it only performs comparisons from one release to the next, so what we did was download one of the tools that makes up upstream-tracker and ran it against the specific release we were using and the release to which we were intending to upgrade to. This provides a report of the symbols that have changed in the public API to the library, which is just a detailed starting point. Pete On 3/26/13 3:44 PM, Jakob Bohm wrote: You can also read the detailed list in the file CHANGES in the OpenSSL source code download, that file lists the changes, version by version going back several versions. However the file in the latest 1.0.x archive does not list which fixes were made to 0.9.8 after work started on version 1.0.0, so you should get both the latest 0.9.8 source download and the latest 1.0.x source download and compare the CHANGES files from both. Hopefully all the stuff that was fixed in later 0.9.8 releases was also fixed in various 1.0.x releases around the same dates, since this is the normal procedure of the project. Programs compiled against 0.9.8 headers will need to be recompiled before linking with 1.0.1 libraries or using them with 1.0.1 DLLs. This applies whenever any of the digits in the version number changes, but usually not if only the extra letter is changed e.g. from 1.0.1d to 1.0.1e . On 26-03-2013 20:15, Walter H. wrote: the major features that 1.0.x supports are openssl ts (http://www.openssl.org/docs/apps/ts.html) openssl cms (http://www.openssl.org/docs/apps/cms.html) On 26.03.2013 18:50, Gopakumar Pillai wrote: Hi, Can any one point me to a location where I can find the major differences between versions 0.9.8 and 1.0.x? Now that 0.9.8 may not live for long, planning to move to 1.0.x versions. Are they API compatible? Any other restrictions? Thank You in advance. --Gopu __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
for those who don't read openssl-dev Original Message Subject:[openssl.org #3016] openssl ts fix Date: Wed, 13 Mar 2013 16:13:31 +0100 From: Peter Sylvester via RT r...@openssl.org Reply-To: openssl-...@openssl.org CC: openssl-...@openssl.org Hi, I have weakend the Esscertid logic a bit. Only the signer certficate is checked and it must be in the first Esscertid. This resolves issues when TSAs add attribute certs etc. Since RFC 3161 does not require a client to check anything else than the presence of the signer cert (and even is is badly written), I think the verification of a chain in the ess was not appropriate logic. regards
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 11:17 PM, kap...@mizera.cz wrote: That is what we talk about here. Try to check previous posts in this thread. rfc 3126 tells This document mandates the presence of this attribute as a signed CMS attribute, and the sequence must not be empty. The certificate used to verify the signature must be identified in the sequence, the Signature Validation Policy may mandate other certificate references to be present, that may include all the certificates up to the point of trust. The encoding of the ESSCertID for this certificate must include the issuerSerial field. RFC 5035 says If more than one certificate is present, subsequent certificates limit the set of certificates that are used during validation. Certificates can be either attribute certificates (limiting authorizations) or public key certificates (limiting path validation). The issuerSerial field (in the ESSCertIDv2 structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates required for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of certificates used in validating the signature. The time stamp does not include issuerSerial in the second esscertid. There is no specification of any profile of time stamps that indicates that a client MUST support attribute certs. I do not think that the authors of 3161, 3126 has in mind any support of attribute certs. I don't recall any profile requiring this. if a timestamp ess would be ok with an attribute cert, what is the client supposed to do? It can verify the signatures of the attribute cert up to some trust anchor, but then? what authorisation is supposed to be checked? that the tsa is allowed to issue certs for a particular policy? (don't yes, maybe). if the TSKlient is able to do something non stadardized special verification, use that one. Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/12/2013 09:30 AM, kap...@mizera.cz wrote: RFC 3161 is written badly. The whole text was a joke anyway. The requester SHALL verify that the TimeStampToken contains the correct certificate identifier of the TSA One may conclude that openssl should simply not validate anything else than the first certificate. And simply ignore the rest of the ESS sequence. Probably with an option. It must not be there, if the attribute cert is available. If the TSQ is with -cert = the TAC certificate is included in TSR. (I know - it is not in our example which is nocert). Is there anywhere in the policy of the TSA an indication about what a client is supposed to do with the atribute certificate, i.e. where is the documentation of the behaviour of their own client. There are two OID as attributes. . That is what about I fight with the Certification Authority. I was (I am) afraid if their timestamps are rfc 3161 compliant or not. They claim YES. What do you thing ? You can add critical extensions into the signing cert, whatever you want, you remain conformant but not interoperable. I'm not sure - on one side you are right: authors of 3161, 3126 has in mind any support of attribute certs but on the other side: rfc 3161 simply refers to RFC 2634 where are attr. certs mentioned = they may (can) be there and should not preclude verification process = the client MUST be able understand all what is in tree with 3161 as root. That's because the authors of RFC 3161 had probably overlooked the possibility of attribute certs. T he only reason for using ESSCert was to include a reference to the signing cert (and maybe its chain), but not to allow all options. Although the text says (last sentence): If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates. I do not think that the last sentence means attribute certificates. In fact RFC 3161 doesn't tell what one has to verify, And, as said in the beginning, there is nothing in the text that says that a client has to verify anything beyong the TSA's signature cert. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]). Here one talks about IDENTIFICATION, attribute certs are for something else. BTW: rfc 3126, 5035, ... are not referred by 3161 = in timestamps may be used only and only what is in tree with 3161 as root. = rfc 3126, 5035 are not valid for timestamps. if a timestamp ess would be ok with an attribute cert, what is the client supposed to do? It can verify the signatures of the attribute cert up to some trust anchor, but then? what authorisation is supposed to be checked? that the tsa is allowed to issue certs for a particular policy? (don't yes, maybe). if the TSKlient is able to do something non stadardized special verification, use that one. That is no solution - the Q is: are or are not these timestamps compliant with RFC 3161. Compliant is not the right word, conformant. And since there are no real conformance requirements, the question is almost useless. You may try to use the argument, that the TSA MUST include teh TSA cert into the ESScertid and add and nothing else but that won't word because this argument is French. ;-) The ESS cert that there SHOULD be a issuer and serial. That's not the case. If not, then they have no value. Remark: discussed CA (TSA) is official, one of main CA in our country - whole government things, law (electronic sigs, timestamps, ..), ... depends on such institution. So it is very important Q. The question is interoperability. As said, I think the openssl tests can simply be weakend to only validate the first ESS cert. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 06:43 PM, kap...@mizera.cz wrote: Hello, ... As I know, the attr. certs are not very necessary = that is why I mean, that temporary solution would be to ignore them in verification process. At least in TS it would solve the problem. Just for info: converting te stuff to pkcs7 and verifying with smime works fine. --kapetr __ 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: possible Bug in OpenSSL - rfc 3161 - TSA service
the second ess certid says SEQUENCE { OCTET STRING 52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78 EB 6C D7 AC } by 3721926ea67e877df5f4e35dd3c87397eef33d4f is the hash of the der version of te intermediate cert. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 08:01 PM, kap...@mizera.cz wrote: Of course YES. Timestamp reply is nothing else as CMS SignedData structure. not quite but ts -reply -tokenout converts it to such a thing __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 10:31 PM, kap...@mizera.cz wrote: Dne 11.3.2013 21:42, Peter Sylvester napsal(a): the second ess certid says SEQUENCE { OCTET STRING 52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78 EB 6C D7 AC } by 3721926ea67e877df5f4e35dd3c87397eef33d4f is the hash of the der version of te intermediate cert. it is the sha1 hash itself and it is NOT hash of any cert in verification chain. openssl ts does not support attribute certs AFAIR __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: is openssl supports TLSv1.2
Yes, OpenSSL since *1.0.1* supports TLS1.2 http://www.openssl.org/news/news.html *Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1: ...* * Support TLS v1.2 and TLS v1.1. * * Look here for more overview. **http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support* http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support BR Peter 2013/3/7 Arashad Ahamad araha...@in.ibm.com Hi, is there any idea that openssl support TLSv1.2? Regards Arashad Ahamad *Arashad Ahamad/India/IBM* 02/28/2013 04:37 PM To openssl-users@openssl.org cc Subject is openssl supports TLSv1.2 Hi , I have gone through the change log of openssl implementation and come to know that there is initial support for TLSv1.2 in the openssl library. Can you please conform that latest version of openssl is compliance with TLSv1.2? Please let me know as soon as possible. Regards Arashad Ahamad
Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?
Ording is important. unfortunately the default order shown in the textual form is not the same as for ldap tools. using openssl asn1parse shows the encoding, country code should come first. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to tell when no more progress can be made
On 01/17/2013 12:10 PM, A G wrote: Hi Here http://marc.info/?l=openssl-usersm=124386218929227 It states that ...This is why it is very important to understand that any possible forward progress on any port (and a write operation that returns WANT_READ may have made forward progress!) requires you to retry all pending operations on all ports So am I correct in understanding that an SSL_read() that returned WANT_READ may have made forward progress (even if it did not return any data)? I have an event driven single threaded app that has 3 non blocking ssl sockets. When each socket completes its connection, I have the sockets read until I get a WANT_READ. My understanding is that a WANT_READ means I may now invoke select() and wait until the socket is ready for reading again. you may also receive WANT_WRITE or WANT_READ when you ssl_write. as long as you do not have interrupted ALL, you do not need to select, after a successful operation you can retry the others, or do a select to determine which are actually ready. a select call is only to avoid a cpu intensive loop on the ssl_read/write operations. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: extensions in certifications
On 12/11/2012 09:45 PM, Michael Mueller wrote: Could I get a nudge. I'd like to get the SANs to show up in my certs. in my request: Requested Extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Subject Alternative Name: DNS:ossvirt4, DNS:gws001 these are not dns names. you should review what your client hosts have as a default domain, etc. It is not obvious whether browsers will accept this regarding the hint (and solution) about copying the extension, you should check what you receive as a cert request, e.g. whether someone wants a CA cert for example. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine
On 12/07/2012 11:05 AM, LN wrote: I have a feeling it does so because I tried to save that returned EVP_PKEY to a PEM file with PEM_write_bio_PrivateKey and then to load it back from the same file with PEM_read_bio_PrivateKey. Saving worked, but loading failed (with some decoding error inside openss). The length of the base64 string in the PEM file for the key was very small in comparision with what is usually the length for private keys. Often, at least for other HSM, a private key returned does not contain the real p and q values but just some index to enumerate a key in the hsm. These are normally some small numbers and not big primes. you might see this if you do openssl rsa -text yourfile
Re: This is one for the Pros: cert is not privkey
Dave, Thank you for the quick and thorough response. This is good stuff. Yes, so the files I will be encrypting will be over 100 bytes. I am aware of the key size requirements - 1028 was only used as a placeholder for the example commands I provided. Does this mean that I will be able to use RSA or not? You lost me with the chaining and AKI stuff. I have no idea what either of those mean. Does the CMS approach that you suggested address this issue? In either case, I like the idea of using CMS. The major reason that I am using the x509 (or originally the ca) utility is that I want to be able to set begin and end valid dates (-startdate, -enddate**) for the public and private keys and create certificates as well. I also want to associate some metadata with them like organization and locality, for that I am currently using the -subj command. Am I correct that the large PEM file includes both a public and private key? If so I should be able to extract them from the PEM and then use something (rsautl, enc or ...) to encrypt and decrypt the files. After successfully extracting what I understand to be a public key from the PEM, I receive this error from the rsautl utility: unable to load Public Key. Error in rsautl Could you give me some examples of how you would use CMS or, just use these utilities properly, to achieve what I'm trying to do. I really appreciate your help. Thanks, Peter On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Peter Parker Sent: Tuesday, 20 November, 2012 20:59 Subject: This is one for the Pros Not really. This is pretty basic. I've been trying to generate a public/private key pair after generating the certificates, but OpenSSL keeps giving me an error. The commands and the error are below. Thanks. No you're not; you're generating a CA keypair and cert (directly), then an application keypair, then an application cert (via CSR). Which is the (well, a) correct sequence, for one entity. Commands #openssl req -new -x509 -extensions v3_ca -days 365 -keyout caKey.pem -passout pass:test -out caCert.crt -batch #openssl genrsa -out application.pem -passout pass:test -des3 1028 1028 is an unusual size for an RSA key; most folks use power-of-2 based values like 1024 1536 2048. 1024 is presently rather marginal for security; for example, NIST has it deprecated since the end of 2010, and prohibited after the end of 2013, for US government use. #openssl req -new -key application.pem -passin pass:test -out application.csr -batch A second req -new -batch generates a CSR with the same DN ... #openssl x509 -req -days 365 -in application.csr -CA caCert.crt -CAcreateserial -CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert ... thus this creates a CA-signed cert which appears to be self-signed, and will not chain correctly with OpenSSL. If the ssl_cert section of your config file (which doesn't exist in the distro file) includes AKI, other software that chains primarily by AKI may work, but this is still incorrect. This puts the cert in a file named test-key.pem, which is a misleading name. #openssl rsa -in test-key.pem -passin pass:test -out pub-key.pem -outform PEM -pubout And therefore this command, which is not the last one, fails because you told it to read the privatekey from a file which is a certificate. application.pem is your privatekey. #openssl rsautl -encrypt -inkey pub-key.pem -pubin -in testfile.txt -out eFile.ssl Error unable to load Private Key (I receive this after the last command) Not last. The key thing that I am trying to do is to encrypt some files with the key that I generate. I do however want to use the public and private keys that I get out of the PEM file using the x509 (or the ca utilities). If (any of) your files are larger than about 100 bytes (for 1024-bit RSA) you can't use raw RSA; even if they aren't, you can't interoperate with properly designed software that doesn't use raw RSA. The conventional approach is to encrypt the bulk data symmetrically with a nonce key (DEK) and PK (RSA) encrypt that DEK; there are numerous schemes that do this, but the one that OpenSSL supports directly is PKCS7/CMS/SMIME. (CMS is an updated Internet version of PKCS7, and SMIME is a simple wrapping of CMS.) You can generate and use RSA keys without using certificates (and without using the req x509 ca utilities) IF you have a way to distribute them correctly -- that is, to make sure the enveloper always uses a correct publickey for the recipient and not a forged, tampered, or obsolete one. (And similarly the verifier for a signer.) Most standard schemes do use X.509 certs for this purpose, because they are also standard. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl
Re: Find the difference in (milli|micro)seconds between two ASN1_TIME values
On 11/07/2012 06:52 PM, Graham Leggett wrote: On 07 Nov 2012, at 4:50 PM, Ted Byers r.ted.by...@gmail.com wrote: Why does it need to be something in openssl? Ideally because it needs to be as secure as openssl. I'm after an accurate time duration between two ASN1_TIME values, that is not dependent on local conditions, or any external libraries. try timegm in perl, or if it needs to be in C, just adopt the code which is just a binary search using the gmtime c function. i.e. you try to set bits to 1, convert to a textual representation untill you find your value. You do not need to know anything about leap years. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: MIME types for PEM encoded CRLs
On 10/27/2012 02:51 PM, Graham Leggett wrote: Section 4.1 says: Encoding considerations: will be none for 8-bit transports and most likely Base64 for SMTP or other 7-bit transports What I'm after is how to interpret section 4.1 in the context of HTTP content negotiation. Regards, Graham -- Whatever you propose as encoding in your client, you will always end up with a der encoded file. You may try to gzip a crl as xxx.crl.gz and do something like the following in an apache .htaccess files *.crl.gz AddType application/pkix-crl .gz AddEncoding gzip .gz /files RewriteEngine on ReWriteCond %{HTTP:accept-encoding} gzip ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$ RewriteCond %{REQUEST_FILENAME}.gz -f RewriteRule ^(.+) $1.gz [QSA,L] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Reference material on how to do certificate validation with OpenSSL
The way how common names are verified in The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software is not correct. It gives a false match when there is more than one common name ava __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Missing entries in index.txt database - Generating CRL
On 08/09/2012 12:57 PM, int0...@safe-mail.net wrote: Hi ... After that I generated a CRL (I own the CA) which then contained the certificate with the serial 0x06. My question now is, would that be a proper workaround or is there a better solution? Since the CRL only contains the serial numbers of the certificates, this seems to work although it is not a very good solution. It is a workaround if you consider the ca and crl commands as the only officially blessed way to manage certificats,. just because it looks convenient at first glance. You may consider not to use the ca command at all, generate certs using x509 instead, manage their status in whatever database you like and, in order to create a crl using crl, you just create a temporary file with the R entries, etc. You may even go further and not use crl at all but create an asn.1 input for asn1parse, I leave this idea as an exercise .. in other words, once you have understood that you only need some file that has Rs and numbers, ... your mind should be free to create them in any way you want. Thanks for your help, Martin __ 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: create certificate request programmatically using OpenSSL API
You can take the code in apps/req.c and extract the pieces you need. On 07/20/2012 10:17 AM, Abyss Lingvo wrote: Hi all! How to create certificate request programmatically via OpenSSL API? This is the solution for command line utility: openssl genrsa -out server_key.pem -passout pass:$passwd -des3 1024 openssl req -new -key server_key.pem -passin pass:$passwd \ -passout pass:$passwd -out server_req.pem -days 1095 \ -subj /C=US/ST=City/L=City/O=company/OU=SSLServers/CN=localhost/emailAddress=sslser...@company.com How to do the same but using OpenSSL API? Best Regards xidex
Re: TS verify: how to fix Verify error:self signed certificate in certificate chain ?
On 07/10/2012 02:38 AM, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Sandro Tosi Sent: Monday, 09 July, 2012 10:15 /usr/bin/openssl ts -verify -sha256 -untrusted CERT -CAfile CA -data FILE TO MARK -in TSA REPLY and the output we get is: 140119872083624:error:2F06D064:time stamp routines:TS_VERIFY_CERT:certificate verify error:ts_rsp_verify.c:246:Verify error:self signed certificate in certificate chain We're using a Debian system, so we copied the CA into /etc/ssl/certs/ but we still see that problem: how can we fix it? is there a way to get a more descripting trace of the problem? Can we run manually all the steps to verify the reply? Your problem is not verifying the message itself, but verifying the certificate that assures it. removing the CA root from the CERT may help. at least I think that CERT must not contain any self signed cert, this is what the error message seems to suggest __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
What changed in the semantics of the openssl verify command?
Here's a series of commands: git clone https://git.eff.org/public/observatory.git cd observatory # get the server response for twitter.com ./scan/FasterCertificateGrabber.py twitter.com # split it into component PEM certs ./inspect twitter.com.results cd certs # now try to verify it. Note that allcerts was a poorly chosen directory name. It should have been allCAs... openssl verify -untrusted twitter.com.results_2.pem -CApath ../allcerts/ twitter.com.results_1.pem # with openssl 0.9.8*, the above command will print # twitter.com.results_1.pem: OK # # but with 1.0.1c, it gives: # twitter.com.results_1.pem: 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 CA # error 20 at 1 depth lookup:unable to get local issuer certificate -- Peter
Re: What changed in the semantics of the openssl verify command?
Hrm, I've worked out why this was failing with 1.0.1c; the symlink for the VeriSign Class 3 G5 root was missing from that repo's CApath. This doesn't entirely explain why the same exact sequence of commands verifies successfully on a machine with openssl 0.9.8o... On 9 July 2012 16:59, Peter Eckersley peter.eckers...@gmail.com wrote: Here's a series of commands: git clone https://git.eff.org/public/observatory.git cd observatory # get the server response for twitter.com ./scan/FasterCertificateGrabber.py twitter.com # split it into component PEM certs ./inspect twitter.com.results cd certs # now try to verify it. Note that allcerts was a poorly chosen directory name. It should have been allCAs... openssl verify -untrusted twitter.com.results_2.pem -CApath ../allcerts/ twitter.com.results_1.pem # with openssl 0.9.8*, the above command will print # twitter.com.results_1.pem: OK # # but with 1.0.1c, it gives: # twitter.com.results_1.pem: 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 CA # error 20 at 1 depth lookup:unable to get local issuer certificate -- Peter -- Peter
Re: X.509 certificate subject format
On 07/02/2012 10:34 AM, Johannes Bauer wrote: Hi list, 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. beware, you are using a textual representation which is probably the one of openssl. So C=SE is the first in the DN sequence. Note that there is also the possibility to put several attribute into one RDN. I.e.: Does the order of elements matter? Yes. Does the order matter when fields are duplicate, i.e. are: subject1= /CN=foo/CN=bar subject2= /CN=bar/CN=foo equal? No. If they are not equal, does the first one have a special meaning? X.509 and RFC 5280 defines a hierachical order of the relative disdintiguised names that make up the sequence of the distinguished name. For example, assume a webserver with a duplicate common name field. Are both names valid as the server name then? No. 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 depends on the implemention of the client, and also whether you have a subjectAltName extension. If there is a sibjectAltName extension, the common name is (not supposed to be) used by a client. 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 certificate signature may be cryptographically valid, but not the name chain in a path validation. At least it shouldn't, there had been errors in some toolkits in the past that treated the hierarchy as a heap of attributes. /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AUTO: Peter Birk pb...@us.ibm.com is out of the office until July 16th, 2012
I am out of the office until 07/16/2012. I'm out of the office until July 16th, 2012. I will have limited network access but will likely be checking for urgent emails daily. If you have questions about any of the following projects, please contact those listed below. For all other questions, please contact my manager Carlos A Hoyos caho...@us.ibm.com. Thanks! IBM Certificate Authority / Client Certificates:Gabriel Pereira Borges gpbor...@br.ibm.com Simplified Web SSO: Michael K Ackerbauer mac...@us.ibm.com ISAM ESSO 8.2 Pilot: Michael K Ackerbauer mac...@us.ibm.com Two-Factor Authentication: Michael K Ackerbauer mac...@us.ibm.com Encryption Recovery Service: Pedro Irlandini Endres de Oliveira pedr...@br.ibm.com Endpoint Registration Service: Pedro Irlandini Endres de Oliveira pedr...@br.ibm.com Regards, Pete Note: This is an automated response to your message RE: Client certificate verification: performance sent on 07/02/2012 20:53:10. This is the only notification you will receive while this person is away.
Re: Client certificate verification
On 06/29/2012 09:29 PM, Sukalp Bhople wrote: Hello, I am trying to measure server performance for client certificate verification. However, there is no significant difference in the server performance when I send one certificate and condition when I send chain of 10 certificates. I am aware that certificate verification is a public key operation. But shouldn't it make some difference? is there any cashing mechanism or something else? cash or cache. cache is french. -- Regards, *Sukalp Bhople.*
Re: self-generated, self-signed root CA and Client Auth Certs not working
On 06/05/2012 07:14 PM, DRings wrote: I've spent too much time trying to figure out something that is probably well know here. I have a restricted community application that seems a perfect fit for using openssl to self-generate our own CA, and self-sign it, and self-generate our own web client authentication certificate and self-sign them. All this so that we can validate the Distinguished Name presented when web browser connecting to our nginx web server. I assume you mean 'sign it by your CA' I have done all this many times but have not been able to get various web browsers to use the self-generated/self-signed client authentication certs. I have imported both the CA.crt and the client.crt into the OS certificate store. But after that the web browser does not seem to use the cert for authentication. I've tried to set the properties on the imported certificate to be used for web client authentication. - it just does not work! Youalso need to configure your server to ask for client certificates of your CA. I just cannot keep spending time on this problem. If I cannot find help, I will urge the the requirement for client certs be dropped from the project. (personal lore) It seems that the web browsers fail because our self-generated/self-signed CA is not signed by some higher CA that is trusted. Is that true or false? They don't fail, they warn that your ca that has signed your server certificate is not installed by default as a trusted ca. If it is false, I need help to overcome the failure of the web browsers to correctly use our certs. Thanks David __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: variable response size of openssl rand on windows
some new line - CRLF conversion may have hit. On 06/04/2012 04:29 PM, Ken Goldman wrote: A typical openssl user error is treating binary data as text. Random numbers are not text until you convert them with -hex. My guess is that Windows is treating some binary character specially, and this causes your version of wc to fail. Linux is handling the binary correctly. So I doubt it's an openssl bug - just a strange interaction with binary streams, Windows, and wc. On 6/3/2012 6:34 PM, alexis _ wrote: I tried to generate 100 bytes using openssl rand 100 But i observed on my Windows machine (openssl from cygwin) that sometimes the result is not always 100 bytes long, I experienced 101, 102... However, while using -hex switch, the variable size issue does not seem to reproduce. Observation does not reproduce at all on Ubuntu 12.04 btw (see version info below) Do you guys reproduce the behavior ? Am i missing something obvious ? is it related to my environment ? is it an openssl bug (i have not seen anything like this on http://rt.openssl.org/index.html?q=rand) __ 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: Can not enable via padlock
Are you combining version 1.0.1 and 1.0.0 ? From: salatiel.fi...@gmail.com Subject: Can not enable via padlock Date: Wed, 30 May 2012 20:26:45 -0300 To: openssl-users@openssl.org I am trying to test via padlock using 'openssl speed -engine padlock', but it fails. # openssl version OpenSSL 1.0.1c 10 May 2012 # openssl engine padlock 140291115067048:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521: 140291115067048:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=padlock # strace openssl engine padlock 21 | grep -i padlock.so open(/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so, O_RDONLY) = 3 # ls -la /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so -rw-r--r-- 1 root root 6096 May 11 12:51 /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so # dmesg | grep -i aes [ 284.335338] padlock: Using VIA PadLock ACE for AES algorithm. # lsmod | grep -i aes padlock_aes 5633 0 aes_generic 25714 1 padlock_aes What am i doing wrong ? __ 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: Cert order in .pem format
On 05/18/2012 06:03 AM, kthiru...@inautix.co.in wrote: Team, Had a query in the certs that we load, The CA's provide our certs in .p12 format, which we need to convert to a .pem and load to SSL structure during initialization. On converting to .pem, it is in the following format, Private Key, CA Certs and Domain Certificate. In our code, we use the below snippet to load keys in in SSL structure, 1. err = SSL_CTX_use_certificate_chain_file(ctx, KeyFile); 2. SSL_CTX_set_default_passwd_cb(ctx, passwd); 3. err = SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM); 4. SSL_CTX_check_private_key(ctx); When i use the same order in the key ( Private Key, CA Certs and Domain Certificate ), the above fails in step 3. So we have to rearrange this order to Domain Certificate, Private Key and CA Certs for the above snippet to work properly. We are trying to reduce the effort here, for someone to rearrange this cert order. Can you suggest some other way to convert the certs as expected by the code or change the order of our code. load the P12 file directly in your code
Re: Are those TLS-SRP cipher suites supported?
On 05/14/2012 02:59 PM, marek.marc...@malkom.pl wrote: Hello, $ openssl version OpenSSL 1.0.0 29 Mar 2010 $ openssl ciphers -V For SRP one should use the 1.0.1 version. openssl version OpenSSL 1.0.1 14 Mar 2012 openssl ciphers SRP SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PHP openssl_x509_parse extensions=subjectAltName
Yes, it can probably be parsed by any ASN.1 parser. But the OID is private - only the organization knows how to interpret it (or what to do with it). private/public in this context refers to governance/ownership not to visibility. if the organisation documents the any interested party can interpret it. 311 is one of microsoft's OID branches smart cad login with UPN is documented at least in http://support.microsoft.com/kb/281245 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to trust a 'root' certificate
On 04/26/2012 03:58 PM, Tammany, Curtis wrote: I don't see this as an Apache issue. The site has required client certs for years now and Apache was configured to require client certificates. I have intermediate DOD certs on the server but OpenSSL sees my DoD Root certificate as un-trusted self-signed so the chain is broken. From http://www.openssl.org/support/faq.html: 5. Why doesSSL program fail with a certificate verify error? This problem is usually indicated by log messages saying something like unable to get local issuer certificate or self signed certificate. When a certificate is verified its root CA must be trusted by OpenSSL this typically means that the CA certificate must be placed in a directory or file and the relevant program configured to read it. The OpenSSL program 'verify' behaves in a similar way and issues similar error messages: check the verify(1) program manual page for more information. How can I get OpenSSL to trust my DOD root certificate? In general all certificates that you have in the apache as client CAs are trusted but they need to chain up to some root which must be part of the set. If the certficates are in a directory, and you have changed the openssl version, you might want to rehash. The hash logic had been changed at some version. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to trust a 'root' certificate
On 04/26/2012 05:20 PM, Tammany, Curtis wrote: In my htaccess file I have the following: SSLRequireSSL SSLVerifyClient require SSLVerifyDepth 5 SSLOptions +ExportCertData In my httpd.conf file, I have the following: SSLCACertificatePath conf/certs/ SSLCACertificateFile conf/certs/DOD_EMAILCerts.crt I am not sure which one takes precedence, but having both is probaly not ok with apache. Try : cd conf/certs/ c_rehash That's for linux. But for windows, the openssl logic is the same, it open the file. opensll doesn't know whether it is a link or a file. So DOD_EMAILCerts.crt contains the root cert plus many intermediates. The site has been working fine for the most part for years. We are tracking SSL_CLIENT_VERIFY in our log file and with some Windows 7 clients, they cannot connect and we are seeing FAILED:unable to get local issuer certificate in the log. As I said in an earlier email, used the openssl version -d command and it responded: OPENSSLDIR: c:/openssl-1.0.1/ssl That folder does not exist. Running openssl verify DOD_EMAILCerts.crt (with the cert file in the bin folder) returns: DOD_EMAILCerts.crt: C = US, O = U.S. Government, OU = DoD, OU = PKI, CN = DoD Root CA 2 error 18 at 0 depth lookup:self signed certificate OK with that command you are verifying the first cert in that file, and since it it is probably self signed, you cannot do that. If, on the other hand you happen to have an intermediate as the beginning you get the other cannot find issuer message. From http://www.madboa.com/geek/openssl/ I read: error 18 at 0 depth lookup:self signed certificate. Unless you make an exception, OpenSSL won’t verify a self-signed certificate. They also go on to say: How do I get OpenSSL to recognize/verify a certificate? Put the file that contains the certificate you’d like to trust into the certs directory discussed above. Then create the hash-based symlink. Here’s a little script that’ll do just that. #!/bin/sh # # usage: certlink.sh filename [filename ...] for CERTFILE in $*; do # make sure file exists and is a valid cert test -f $CERTFILE || continue HASH=$(openssl x509 -noout -hash -in $CERTFILE) test -n $HASH || continue # use lowest available iterator for symlink for ITER in 0 1 2 3 4 5 6 7 8 9; do test -f ${HASH}.${ITER} continue ln -s $CERTFILE ${HASH}.${ITER} test -L ${HASH}.${ITER} break done done That is for Linux. How do I get OpenSSL to recognize/verify a certificate on Windows XP/2003? (like step-by-step instructions). ... instead of ln -s you can create a copy ... for more detailed instruction, I'll can charge you 100EUR per line. :-) ... ... Just put all the CA certificates into one file and remove the SSLCACertificatePath and just keep the SSLCACertificateFile Thanks. Curtis -Original Message- From: Peter Sylvester [mailto:peter.sylves...@edelweb.fr] Sent: Thursday, April 26, 2012 10:40 To: openssl-users@openssl.org Cc: Tammany, Curtis; Bernhard Fröhlich Subject: Re: How to trust a 'root' certificate On 04/26/2012 03:58 PM, Tammany, Curtis wrote: I don't see this as an Apache issue. The site has required client certs for years now and Apache was configured to require client certificates. I have intermediate DOD certs on the server but OpenSSL sees my DoD Root certificate as un-trusted self-signed so the chain is broken. From http://www.openssl.org/support/faq.html: 5. Why doesSSL program fail with a certificate verify error? This problem is usually indicated by log messages saying something like unable to get local issuer certificate or self signed certificate. When a certificate is verified its root CA must be trusted by OpenSSL this typically means that the CA certificate must be placed in a directory or file and the relevant program configured to read it. The OpenSSL program 'verify' behaves in a similar way and issues similar error messages: check the verify(1) program manual page for more information. How can I get OpenSSL to trust my DOD root certificate? In general all certificates that you have in the apache as client CAs are trusted but they need to chain up to some root which must be part of the set. If the certficates are in a directory, and you have changed the openssl version, you might want to rehash. The hash logic had been changed at some version. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RE: OpenSSL 1.0.1a
On 01/-10/-28163 08:59 PM, Spence, Thomas CIV USAF AFDW 844 CS/SCOX wrote: I am using AIX 5.3 with gcc 4.3.5. ld: 0711-317 ERROR: Undefined symbol: OPENSSL_ia32cap_P I had the same problem with the file crypto/evp/e_rc4_hmac_md5.c. Linking on non-x86 hardware failed. Try to replace this file with a newer version from openssl-1.0.1-stable-SNAP-20120420.tar.gz (or a later snapshot). -- Peter Heimann __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SRP in OpenSSL 1.0.1
On 04/04/2012 11:01 AM, Christian Weber wrote: Dear users and developers, we just read through some of the code examples for SRP usage. Concerning the necessary callbacks we wonder why in s_server.c the verifier parametrization is being delayed. Within apps/s_server.c we can find the comment: When the callback is called for a new connection we return with a negative value. This will provoke the accept etc to return with an LOOKUP_X509. The main logic of the reinvokes the suspended call (which would normally occur after a worker has finished) and we set the user parameters. There seems to be something missing between 'the' and 'reinvokes', so we cannot understand what's being meant. application: Imagine a server that has a large base of users. When the callback is invoked, it would start with some asynch ldap call or whaever else to read a verifier. The callback would return -1, and the SSL_accept fails with the return code ERROR_LOOKUP_X509 (well, I know, by this name was the only one available, borrowed by a reciprooque feature in the client. The application would do some select call on whatever filedescriptors. As soon as the verifier is available, the application stores this somewhere, and calls SSL_accept again, which in this case will cause the callback to return the verifier. Nothing about srp is documented so far. The code in apps/server.c is not doing any select loop, it just calls the SSL_accept twice. This is done to illustrate the possibilities of the callback. The callback 'pretends' that the data are not there. I do not really like to use the verifier file as it is done in the example, since one needs to restart a server after modifying a user. May it be a security impact to implement the lookup within the callback itself (as done in ssl/ssltest.c, based on user's password) or may there be other error conditions which are covered by relocating the lookup to init_ssl_connection in apps/s_cerver.c? As I wrote abone, the while loop to do SSL_accept is not exactly what you would want to do in a real application. The simulated logic flow is: i=SSL_accept(con); if ( i = 0 SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP ) do whatever is necessary to get the verifier, in this case simulated by srp_callback_parm.user = SRP_VBASE_get_by_user(srp_callback_parm.vb, srp_callback_parm.login); since there is nothing async to do in the example. and then do another i=SSL_accept(con); I could have folded out the loop to get out the init_ssl_connection etc. Any opinions about possible security weakening against implementing the lookup within the callback? There may be many ways to store and create a verifier. One could for example on the fly generate a one time password, send it as an SMS, store the verifiers in an LDAP. Therefore the callback allows an application to choose whatever means it wants to implement, openssl is not charged to read files, make network requests or whatever. Peter TIA -- Christian Weber __ 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: How to get the Certificate Keyusage retire error ? (lCert-ex_kusage =0)
On 04/04/2012 02:51 PM, brajan wrote: I am using openssl 0.9.8g version . i convert the PEM certificate file to X509 format and try to read the key usage value . Keyuage =lCertificate-ex_kusage ; Some time the keyusage = 128 Some time Keyusage is 0 for the same certificate . why this problem occurs ... the flags are set by one of functions in crypo/v3_purp.c try callX509_check_ca(lCertificate) before accessing __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1beta1, incompatibility with gnutls?
On 03/08/2012 11:05 PM, David Holmes wrote: I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli). s_server is complaining of an unknown extension (see debug output below). Isn't it the client after the serverhello response? you might want to add -debug and -msg to see the s_server response to what s_server responds and why the client aborts. regarding my earlier hasty message today: the illegal hostname 17.0.0.1 is not a problem in s_server. (I still haven't passed all ent certification) :-) Openssl 0.9.8h works just fine though. Is this a known issue? ./openssl s_server -key src/data/server.key -cert src/data/server.crt -tlsextdebug Using default temp DH parameters Using default temp ECDH parameters ACCEPT TLS client extension unknown (id=9), len=3 - 02 00 01 ... TLS client extension server name (id=0), len=14 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31 .127.0.0.1 ERROR 4150167176:error:14094456:SSL routines:SSL3_READ_BYTES:tlsv1 unsupported extension:s3_pkt.c:1240:SSL alert number 110 shutting down SSL CONNECTION CLOSED ACCEPT David Holmes | Technical Marketing Manager - Security F5 Networks P 206.272. F 206.272.5556 www.f5.com D 206.272.6740 Follow @dholmesf5 __ 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: 1.0.1beta1, incompatibility with gnutls?
On 03/08/2012 11:05 PM, David Holmes wrote: I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli). s_server is complaining of an unknown extension (see debug output below). Openssl 0.9.8h works just fine though. Is this a known issue? try beta3, should work better. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1beta1, incompatibility with gnutls?
On 03/08/2012 11:05 PM, David Holmes wrote: I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli). s_server is complaining of an unknown extension (see debug output below). Openssl 0.9.8h works just fine though. Is this a known issue? 127.0.0.1 is not a valid servername. I don't remember but you might want to play with the servername parameter of s_server. ./openssl s_server -key src/data/server.key -cert src/data/server.crt -tlsextdebug Using default temp DH parameters Using default temp ECDH parameters ACCEPT TLS client extension unknown (id=9), len=3 - 02 00 01 ... TLS client extension server name (id=0), len=14 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31 .127.0.0.1 ERROR 4150167176:error:14094456:SSL routines:SSL3_READ_BYTES:tlsv1 unsupported extension:s3_pkt.c:1240:SSL alert number 110 shutting down SSL CONNECTION CLOSED ACCEPT David Holmes | Technical Marketing Manager - Security F5 Networks P 206.272. F 206.272.5556 www.f5.com D 206.272.6740 Follow @dholmesf5 __ 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: Distinguishing a CA certificate from an end entity certificate Reg.
On 02/23/2012 10:49 AM, Ashok C wrote: Hi, What would be the most efficient and easiest way to distinguish a CA certificate from an actual server/client(end entity) certificate? We were thinking of identifying the CA with the CA:TRUE constraint from the text display, but again this check does not cover x509 v1 certificates where this extension is not present. Is there any command/openSSL API available which would serve this purpose? a v1 certificate (if you want) or v3 cert with both CA:true*and keyusage has certsign bit. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Customer Enterprise X.509 Extension OID Assignment
On 02/06/2012 09:41 AM, Curt Sampson wrote: If I were to create a custom X.509 certificate extension for use within my enterprise and with others outside who wanted to write or modify their own software to interoperate with it, I'd need to assign an OID for this extension, right? And for that, would the standard way to do this be to assign an OID underneath the one assigned to us by the IANA in their Private Enterprise Number list[1], right? It is one possible way, you need to find someone that owns an OID (forever) and dedicates you a number. in france, every enterprise has an oid 1.3.2.officialenterprisenumber some institution sell such numbers. (I note that [1] claims to be the SMI Network Management Private Enterprise Codes, but I gather that others use this for pretty much anything where they need a unique OID.) I'd prefer to say non-ambiguous. besides that, I would also investigate your need for a custom extension, if you use it for 'identity', then use a subjectAltname for example if you use it for some kind of attribute based authorisation, well, you are maybe overloading the certificate. Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
reference docs at old sial.org
Hi, Just wanted to let the users of openssh know that the old reference documents from sial.org, which provided a handy discussion of maintaining a certificate authority and other aspects of use of openssh, are now back online at http://novosial.org. The sial.org domain was sold several years ago and the contents replaced by the domain name reseller. Since the original author, Jeremy Mates, placed the documents in the public domain, they are available online again in one collection at this new site. cheers, Peter N. Steinmetz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Separating the digest and signature steps of RSA signing
Hi all, I have an offline system that needs to compute RSA signatures over large blobs of data, given only hashes of the data as input and not the entire blobs (something like the NONEwithRSA algorithm in Java's RSA implementation http://www.docjar.com/docs/api/sun/security/mscapi/RSASignature.html) Is there any way to do that with openssl? -- Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SRP problem in OpenSSL 1.0.1 beta
On 01/10/2012 04:52 AM, Norm Green wrote: Hi, I am testing my application with the 1.0.1 beta and noticed the errors generated are not very friendly when SRP credentials are incorrect. The problem is that the error codes returned in no way indicate that the problem is incorrect credentials. Instead I see errors about bad record mac (see below). two things: - your server code may choose to react with a o unknown_psk_identity (115) - this alert MAY be sent by a server that receives an unknown user name. This alert is always fatal. SeeSection 2.5.1.3 http://tools.ietf.org/html/rfc5054#section-2.5.1.3 for details. this can be done in the callback if one chooses so. - when a user provides a bad password, there is no common secret, there is only one possible error: something was wrong during the handshake Everything works just fine when the correct credentials are used. What I need a way to discern if incorrect credentials were supplied, or there is some other error. As it stands now, I would have to assume that the credentials are wrong whenever SSL_connect() or SSL_accept() fail, which seems like a poor assumption. You can only assume that either a wrong password is given or some network problem has occured. You cannot determine whether you are talking to the right partner without a successful handshake. I'm still fairly new to SSL and SRP and am grateful for any and all help. does that help? btw: if your server needs non blocking behaviour (even if no), and you need time to lookup a credential (a verifier) in a database, you can indicate in your callback to interrupt the accept call (in blocking and non blocking mode) and repeat the accept as soon as the data are there. Norm Green VMware, Inc. Peter Sylvester
Re: SRP problem in OpenSSL 1.0.1 beta
an excerpt from rfc 5054 paragraph 3.3 If an attacker learns a user's SRP verifier (e.g., by gaining access to a server's password file), the attacker can masquerade as the real server to that user, and can also attempt a dictionary attack to recover that user's password. An attacker could repeatedly contact an SRP server and try to guess a legitimate user's password. Servers SHOULD take steps to prevent this, such as limiting the rate of authentication attempts from a particular IP address or against a particular user name. ... If the client receives an unknown_psk_identity alert in response to a client hello, this alert may have been inserted by an attacker. The client should be careful about making any decisions, or forming any conclusions, based on receiving this alert __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Displaying Serial Number of Cert via s_client ?
On 01/07/2012 02:01 AM, Ken Adler wrote: I use echo GET | openssl s_client -connect www.google.com:443 -state to troubleshoot https handshakes. Is there a way to get it to return the Serial number (or thumbprint) of the server certificate? openssl s_client -connect www.google.com:443 21|openssl x509 -noout -serial serial=4F9D96D966B0992B54C2957CB4157D4D __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and apache2 wildcard self-signed certificate for nested subdomain
On 12/14/2011 01:33 PM, rey sebastien wrote: Hello users :) I have some problem with nested subdomain and wildcard openssl certificate.. perhaps this is because the subdomain type is : site1.parisgeo.cnrs.fr, or site2.parisgeo.cnrs.fr, or other subdomain like .parisgeo.cnrs.fr When i create the self signed certificate, i enter CN = *.parisgeo.cnrs.fr, but it's seems it's impossible to connect on this site for example partage.parisgeo.cnrs.fr with this configuration ! Arg. your connexion works fine up to the point of certificate verification. openssl s_client does not like self signed certs any browser needs user action to disable warnings. example curl -k https://www.parisgeo.cnrs.fr works because of -k
Re: revoking a certificate without having to provide pass phrase as next step
I know. that's why i'm looking for a way, where I can provide it in some way other than needing to interact with system. 2011/11/29 Curt Sampson c...@cynic.net On 2011-11-29 04:15 +0100 (Tue), Peter wrote: It generally works, but after the command above is sent, i have to type in pass phrase manually. I need it to be done automatically. I believe you can just remove the passphrase from the key file. This of course has the obvious security implications. cjs -- Curt Sampson c...@cynic.net +81 90 7737 2974 http://www.starling-software.com/ I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
revoking a certificate without having to provide pass phrase as next step
Hi, I'm trying to find a way to make my PHP scipt capable of automatic certificate revocation. The script is run from console and the line looks like this: exec(openssl ca -keyfile ca.key -cert ca.pem -revoke .$userId..pem); which works like this: openssl ca -keyfile ca.key -cert ca.pem -revoke 04.pem It generally works, but after the command above is sent, i have to type in pass phrase manually. I need it to be done automatically. Is there any way to achieve this? I looked through manual but didn't find any information on how and if this could be done. Regards, Peter
Re: How to create certificate store using DER and PKCS12 certificates
On 11/10/2011 12:47 PM, Rajib Karmakar wrote: Hi, I am using OpenSSL version 1.0.0e and want to create a certificate store using DER and PKCS12 formatted certificates. I have to read and convert DER and PKCS12 certificates into X509 object and add them into X509_STORE. But if PEM, DER and PKCS12 certificates are stored in same path I have to identify each certificate format. Is there any OpenSSL API that tells the certificate format? You try to decode them in all formats, only one of them will succeed.
Re: OpenSSL 1.0.1 example with SRP
On 10/25/2011 05:15 AM, Norm Green wrote: Hello Experts, I'm new to OpenSSL so please bear with me. I'm trying to construct a simple example that uses a recent OpenSSL 1.0.1 snapshot to create secure connection using SRP without using any certificates. I am aware 1.0.1 is not yet released, but I've been told this should be possible. try this first with s_client and s_server you need cipher SRP fo them what happens when you connect to your server with openssl s_client -srpuser USER -cipher SRP -connect server:port __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Unable to enable GOST ciphers support
Hi! I'm trying to enable GOST ciphers in openssl-1.0.0e and so far I failed. What I've done so far: 1. built openssl with ./config shared zlib enable-rfc3779 --prefix=/tmp/gost-ssl-new 2. updated config file as described in README.gost. I've straced openssl run and I'm sure it reads my configuration file (attached to this mail) and I'm sure there is /tmp/gost-ssl-new/lib/engines/libgost.so. But nevertheless openssl does not open this binary (conclusions from strace) and no GOST ciphers available. I've tried to do exactly same steps installing openssl system wide (prefix=/usr) but still no luck. Could you help me to understand what am I doing wrong? Is there any way to debug what openssl loads from configuration file and how it parses that? Thank you in advance for any pointers, -- Peter. HOME= . RANDFILE= $ENV::HOME/.rnd engines = engine_section [engine_section] gost = gost_section [gost_section] engine_id = gost dynamic_path = /tmp/gost-ssl-new/lib/engines/libgost.so default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet tablet gost-ssl-new # strace -e open ./bin/openssl ciphers open(/tmp/gost-ssl-new/lib/tls/x86_64/libssl.so.1.0.0, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/gost-ssl-new/lib/tls/libssl.so.1.0.0, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/gost-ssl-new/lib/x86_64/libssl.so.1.0.0, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/gost-ssl-new/lib/libssl.so.1.0.0, O_RDONLY) = 3 open(/tmp/gost-ssl-new/lib/libcrypto.so.1.0.0, O_RDONLY) = 3 open(/tmp/gost-ssl-new/lib/libdl.so.2, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/ld.so.cache, O_RDONLY) = 3 open(/lib64/libdl.so.2, O_RDONLY) = 3 open(/tmp/gost-ssl-new/lib/libz.so.1, O_RDONLY) = -1 ENOENT (No such file or directory) open(/lib64/libz.so.1, O_RDONLY) = 3 open(/tmp/gost-ssl-new/lib/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory) open(/lib64/libc.so.6, O_RDONLY) = 3 open(/tmp/gost-ssl-new/ssl/openssl.cnf, O_RDONLY) = 3 open(/proc/meminfo, O_RDONLY) = 3 open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
Re: Error converting from .cer to .pem
On 09/19/2011 04:29 PM, ubuntuv wrote: Thanks Jacob. Output of #less evalRootCertificate.cer -BEGIN CERTIFICATE- MIICBDCC.MVWn1dH/IzvUWbQ== -END CERTIFICATE- I even tried removing the following file lines -BEGIN CERTIFICATE- -END CERTIFICATE- # openssl x509 -inform der -in evalRootCertificate.cer -out steel.pem unable to load certificate your file is already in pem form. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to deal with new OIDs
On 09/07/2011 08:28 PM, Dr. Stephen Henson wrote: On Wed, Sep 07, 2011, Dominik Oepen wrote: Are these OIDs are by chance the ones described in ticket 1794? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to deal with new OIDs
On 09/08/2011 04:31 PM, Dominik Oepen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.09.2011 11:49, schrieb Peter Sylvester: On 09/07/2011 08:28 PM, Dr. Stephen Henson wrote: On Wed, Sep 07, 2011, Dominik Oepen wrote: Are these OIDs are by chance the ones described in ticket 1794? Actually I meant 2239. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Becoming a CA for group of internal servers?
you might want to read the description of the -extfile parameter of the x509 command an excerpt from curl-7.21.6/tests/certs/scripts/genserv.sh available at curl.haxx.se $OPENSSL req -config $PREFIX-sv.prm -newkey rsa:$KEYSIZE -keyout $PREFIX-sv.key -out $PREFIX-sv.csr $OPENSSL rsa -in $PREFIX-sv.key -out $PREFIX-sv.key $OPENSSL x509 -set_serial $SERIAL -extfile $PREFIX-sv.prm -days $DURATION -CA $CAPREFIX-ca.cacert -CAkey $CAPREFIX-ca.key -in $PREFIX-sv.csr -req -out $PREFIX-sv.crt -text -nameopt multiline -sha1 with a $PREFIX-sv.prm like the following extensions = x509v3 [ x509v3 ] subjectAltName = DNS:localhost keyUsage= keyEncipherment extendedKeyUsage = serverAuth subjectKeyIdentifier = hash authorityKeyIdentifier = keyid basicConstraints = critical,CA:false [ req ] default_bits= 1024 distinguished_name = req_DN default_md= sha256 string_mask= utf8only [ req_DN ] countryName = Country Name is Northern Nowhere countryName_value= NN organizationName = Organization Name organizationName_value = Edel Curl Arctic Illudium Research Cloud commonName = Common Name commonName_value = localhost [something] # The key # the certficate # some dhparam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org