[openssl-users] cms sign/verify
I am using OpenSSL version 1.0.1f and got problems while signing and verifying a file using these commands: $ openssl cms -sign -inkey Mozart.pem -signer Mozart.crt -binary -in $DOCUMENT -out $DOCUMENT.p7m $ openssl cms -verify -CAfile CAcert.pem -binary -in $DOCUMENT.p7m -out $DOCUMENT.out $ cmp $DOCUMENT $DOCUMENT.out If I omit the -binary option from both calls to openssl cms then the verified document differs from the original document because of translations LF to CR/LF. If I include the -binary option the first call to openssl works fine but the second call throws errors: Verification failure 3073672892:error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure:cms_sd.c:887: 3073672892:error:2E09D06D:CMS routines:CMS_verify:content verify error:cms_smime.c:425: How do I use openssl cms -sign/verify correctly? -- View this message in context: http://openssl.6102.n7.nabble.com/cms-sign-verify-tp58943.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] New FIPS 140-2 SE Validation Approved
On 06/30/2015 07:15 AM, jonetsu wrote: The validation is on the ARM platform using Linux 2.4. I am one of those 'unlucky' having to deal with FIPS so please pardon any silly questions. Would this validation be limited to these two aspects ? The validation is limited to the platforms (Operational Environments) listed for that validation, unless you are able to leverage the user affirmation option per section G.5 of the Implementation Guidance document (one of the canons of FIPS 140-2 scripture). And, is there any money-saving advantage at using an already validated OpenSSL when the whole unit (embedded device) qill be going for validation ? Eg. will it save lab time if they know that the OpenSSL used is already validated ? I'm going to guess that you're trying to obtain a Level 2 validation for a product that contains the OpenSSL FIPS Object Module. Yes, the fact that the OpenSSL FIPS module already has a Level 1 validation can help. But, FIPS 140-2 is a tricky business so you should consult with your accredited FIPS 140-2 test lab for advice specific to your unique circumstances. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] libtlssep
Dear OpenSSL community, I am writing to introduce a new TLS library which presently makes use of OpenSSL: libtlssep. Libtlssep has two aims: (1) to provide a simpler API to application developers and (2) to encourage the decomposition of applications into at least two processes, one of which isolates access to secret cryptographic keys. Georgiev et al., Fahl et al., and other researchers have shown that application developers often misuse existing APIs [e.g., 1, 2]. This work informs aim (1). Aim (2) attempts to bring the privilege separation work of Provos et al. [3] to the domain of TLS in an easy-to-use way. The current implementation of libtlssep sits between an application and OpenSSL. Using libtlssep requires modifying an application to use the API, but we found the amount of work nominal while we ported wget and lighttpd. Of course, new applications could benefit from libtlssep right away. If you are interested in libtlssep, you can find more information at: https://www.flyn.org/publications/2015-libtlssep.pdf A paper in submission with SPACE 2015 that includes a description of libtlssep along with performance measurements and other details. and a research prototype at: https://www.flyn.org/projects/libtlssep/ The libtlssep website. We would love to hear any constructive comments you might have, and would be interested in hearing about any possibility for future collaboration. Thank you, Mike Petullo [1] Georgiev et al.: The most dangerous code in the world: validating SSL certificates in non-browser software. CCS (2012) [2] Fahl et al.: Why Eve and Mallory love Android: an analysis of Android SSL (in)security. CCS (2012) [3] Provos et al.: Preventing privilege escalation. USENIX Security (2003) :wq ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to verify a cert chain using Openssl command line?
Ben, I think you are right. My verify test is okay now if I match the subjectAltName to the nameConstraints defined by the subCA. Thanks. David On Mon, Jun 29, 2015 at 6:23 PM, Ben Humpert b...@an3k.de wrote: Yes, because nameConstraints are inherited. I don't know exactly where the bug lies but I strongly advise NOT to use nameConstraints because while there is a standard nobody has implemented full or correctly working support for it. I ran various tests some weeks ago and the result was horrible. See https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html and https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html 2015-06-29 23:58 GMT+02:00 David Li dlipub...@gmail.com: The subCA has nameConstraints in the subCA configuration file: [name_constraints] permitted;DNS.0 = example.com client configuration file has subjectAltName: subjectAltName = DNS: www.cs.com So is this a mismatch? How come s_client/s_server test was okay? On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert b...@an3k.de wrote: Do you use nameConstraints or have specified IP in subjectAltName? Because OpenSSL can't handle that correctly. 2015-06-29 22:51 GMT+02:00 David Li dlipub...@gmail.com: Hi, As a test, I have created a rootCA, a subCA (signed by the rootCA) and a client cert (signed by the subCA). Now I want to use verify, s_client and s_server to test them together. However I searched and tried a number of times but still unsure about the correct syntax format in verify command. This is what I did: cat rootCA.crt subCA.crt caChain.crt openssl -verbose -verify -CAflie caChain.crt clientCert.crt openssl verify -CAfile caChain.crt client/clientCert.crt client/clientCert.crt: C = US, ST = California, O = David's company, CN = David's client cert, emailAddress = david...@example.com error 47 at 0 depth lookup:permitted subtree violation However it seems my s_client and s_server test is OK: I created a caChain by cancatenating rootCA and subCA together: Server: openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 where serverComb.crt = cat of serverCert and server key Client: openssl s_client -CAfile caChina.crt -cert client/clientComb.crt where clientComb is = cat of clientCert and clientKey Anyone has any idea why verify command failed? Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to provide KDF to ECDH key computation when using EVP API?
On 28/06/2015 04:55, Reinier Torenbeek wrote:
Hi again,
After digging into the ECDH code a bit more, I (sort of) found an answer
to my question.
My reason to look at using the KDF is to apply a hash to the shared
secret to compute a useable key within the derive function. There is a
control value called EVP_PKEY_CTRL_MD which seems like it could be used
for this purpose. However, for EC keys it looks like this control value
only has a meaning for the signing functionality, not for the key
derivation functionality. This looks like an omission to me. A small
test showed that it would not be too hard to have the hash applied when
doing key derivation as well.
If the approach sketched above is not right or possible, then exposing
the KDF function to the user of the EVP API seems a logical alternative.
However, the KDF function prototype is rather limited, with only an in
and out and no context at all. The latter would be required to make it
useful.
Since this functionality looks like it is a kind of half-finished to me,
can anybody give some insight in its status or confirm/correct my
conclusions?
Thanks,
Reinier
On 6/19/15 4:23 PM, Reinier Torenbeek wrote:
Hi,
My goal is to implement ECDH in my own engine. The snippet below shows
the struct that needs to be filled and set as the engine's ECDH method:
struct ecdh_method {
const char *name;
int (*compute_key) (void *key, size_t outlen, const EC_POINT *pub_key,
EC_KEY *ecdh, void *(*KDF) (const void *in,
size_t inlen, void *out,
size_t *outlen));
# if 0
int (*init) (EC_KEY *eckey);
int (*finish) (EC_KEY *eckey);
# endif
int flags;
char *app_data;
};
I intend to leverage the KDF mechanism, but it does not seem to be
exposed in the EVP API. Is that possible at all? If yes, how do I do
that? If no, what is the purpose of the KDF() parameter in compute_key?
How does this all compare to the EVP API for traditional
DH?, I think this is a closer equivalent for API design
than ECDSA.
(By the way, struct ecdh_method is in crypto/ecdh/ech_locl.h, which
seems to be a private header file. Am I supposed/allowed to include it
anyway?)
Unfortunately, someone thinks that OpenSSL should be made
as useless as possible, strangely, this all began shortly
after the heartbleed backdoor was closed.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting
2015-06-24 1:35 GMT+02:00 Jakob Bohm jb-open...@wisemo.com: On 19/06/2015 16:24, Ben Humpert wrote: When the CSR contains an email address and the email_in_dn setting in the config file is set to no the email address is actually present in the issuer DN but not in the subject DN. This causes errors when verifying certificate chains since the subject hash is used to identify a cert but the issuer hash is different. Are you sure, I have not seen this behavior in current versions when making self-signed certificates, could you provide step by step reproduction procedures to cause this misbehavior? I have the openssl.cnf attached. # Step-By-Step below # cd /etc/ssl/ mv /etc/ssl/ca /etc/ssl/ca_orig mkdir -p /etc/ssl/ca/db /etc/ssl/ca/private /etc/ssl/ca/certs /etc/ssl/ca/crl /etc/ssl/ca/out /etc/ssl/ca/reqs chmod 700 /etc/ssl/ca/private cp /dev/null /etc/ssl/ca/db/RootCA.db cp /dev/null /etc/ssl/ca/db/RootCA.db.attr openssl rand -hex 16 /etc/ssl/ca/db/RootCA.crt.srl echo 1001 /etc/ssl/ca/db/RootCA.crl.srl cd /etc/ssl/ca/ openssl req -new -out /etc/ssl/ca/RootCA.csr openssl ca -selfsign -in /etc/ssl/ca/RootCA.csr -out /etc/ssl/ca/RootCA.crt -notext -startdate 15010100Z -enddate 191231235959Z ln -s /etc/ssl/ca/RootCA.crt /etc/ssl/certs/`openssl x509 -hash -noout -in RootCA.crt`.0 openssl verify /etc/ssl/ca/RootCA.crt ln -s /etc/ssl/ca/RootCA.crt /etc/ssl/certs/`openssl x509 -issuer_hash -noout -in RootCA.crt`.0 openssl verify /etc/ssl/ca/RootCA.crt # Step-By-Step above # # Cleanup below # cd /etc/ssl/ rm -rf /etc/ssl/certs/`openssl x509 -hash -noout -in RootCA.crt`.0 rm -rf /etc/ssl/certs/`openssl x509 -issuer_hash -noout -in RootCA.crt`.0 rm -rf /etc/ssl/ca mv /etc/ssl/ca_orig /etc/ssl/ca # Cleanup above # You cannot verify this certificate. OpenSSL always returns error 20 at 0 depth lookup:unable to get local issuer certificate To prevent this, uncomment or completely delete the emailAddress line in your certificate request. openssl.cnf Description: Binary data ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Use an engine in only part of my application
Hi, I have an application A that uses a shared library S that in turn uses the OpenSSL library. But A is also using another shared lib B that in turn uses OpenSSL as well. Is there a way to make such that S uses an OpenSSL engine, but B uses the default functionality? Thank you for your help, Jacques ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting
On 30/06/2015 18:32, Ben Humpert wrote: 2015-06-24 1:35 GMT+02:00 Jakob Bohm jb-open...@wisemo.com: On 19/06/2015 16:24, Ben Humpert wrote: When the CSR contains an email address and the email_in_dn setting in the config file is set to no the email address is actually present in the issuer DN but not in the subject DN. This causes errors when verifying certificate chains since the subject hash is used to identify a cert but the issuer hash is different. Are you sure, I have not seen this behavior in current versions when making self-signed certificates, could you provide step by step reproduction procedures to cause this misbehavior? ... openssl req -new -out /etc/ssl/ca/RootCA.csr openssl ca -selfsign -in /etc/ssl/ca/RootCA.csr -out /etc/ssl/ca/RootCA.crt -notext -startdate 15010100Z -enddate 191231235959Z Ah, I didn't even know about that ca -selfsign option, I generally create my root certs using the req or x509 command directly. I wonder if the ca -selfsign variant takes its email_in_DN option from a different section than regular cert signing. Besides, putting an e-mail attribute in a CSR for a CA seems unusual. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] S/MIME Mails signed with SHA256 certificate and/or SHA256 Hash
On 29.06.2015 10:48, Jakob Bohm wrote: On 26/06/2015 21:41, Walter H. wrote: Hello, has anybody got a reliable source or knowledge about which mail clients - especially which Thunderbird release - should be capable of verifying such mails correctly? I believe GlobalSign has a knowledge base article listing this as far as they know. It is at https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility Enjoy Thanks, the reason why I was asking; there it shows, that Mozilla Thunderbird above 10.x are capable of verifying such e-mails; I recently got such an e-mail and it could not be verified; Thunderbird has shown an error; the certificate used for signing that e-mail also used an sha256-hash, too; at work I had a client capable of sending sha-256 hash signed e-mails, but only a sha1 cert; and that mail could be verfied without problems; could someone please send me an email, where both the mail signature and also the certificate have a sha256 hash; Greetings, Walter smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] New FIPS 140-2 SE Validation Approved
The validation is on the ARM platform using Linux 2.4. I am one of those 'unlucky' having to deal with FIPS so please pardon any silly questions. Would this validation be limited to these two aspects ? And, is there any money-saving advantage at using an already validated OpenSSL when the whole unit (embedded device) qill be going for validation ? Eg. will it save lab time if they know that the OpenSSL used is already validated ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/New-FIPS-140-2-SE-Validation-Approved-tp58909p58944.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
