[openssl-users] SMIME_read_CMS and binary signature
Hello! I need a little hint for parsing SMIME into a CMS_ContentInfo. Here is an shortend example of my SMIME to make clear the structure of my content. Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="=_Part_abcde" --=_Part_abcde Content-Type: application/text; name=abc.txt Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=abc.txt VU...Cc= --=_Part_abcde Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIA...AAA= --=_Part_abcde-- If I try SMIME_read_CMS it is working well if the signature (the 2nd MIME-part with smime-type=singed-data) has a Content-Transfer-Encodeing of "base64" (as it is in my example) But It is not working if the CTE is "binary" and also the content is. If I manually convert the signature to base64 and change the CTE to base64 the SMIME_read_CMS is working again. Is there another way of handling that? Maybe another function? Thanks for help! Best regards, Chris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] c_hash/ca-certificates.crt
Hello! Normally I put new certificates into /etc/ssl/certs and create the hash-link. That workes for me for many years. Just found out 2 new things agout that. 1. There is c_hash that does the creation of the hash-link for me. Great! 2. ca-certificates.crt is there too. It has any certificate inside of it that is also in the directory but not the ones I added by myself over the years. Today was the 1st time I had to add a certificate to thefile because a tool looked into that file and not into the directory. Please what is the relation to the directory and ca-certificates.crt and is there a tool/command to that adds new certificates to the file too? Thanks! CH -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Payload-checksum in PEM?
Hi! I have a verification-error in a SMIME-message and I try to check manually the checksums of the payload. Here is my strategy - but I do not know it is even possible. # openssl cms -sign -in myfile.txt -md md5 -signer cer.txt -inkey key.txt -outform PEM > pem.txt # md5sum myfile.txt Can I expect to find the md5sum checksum somewhere in the ASN1 of pem.txt??? # openssl asn1parse -in pem.txt As far I see it is not there - but maybe it is just a quick step to it? Thanks for help! Chris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Payload-checksum in PEM?
Thanks for your help! But I am not sure I do fully understand that - not doing that every day. Please one more hint - thanks. I have a certificate (cer.txt; content is enclosed with ---BEGIN/END CERTIFICATE---). I can get the public-key out of that. (pubkey.txt; content is enclosed ---BEGIN/END PUBLIC KEY---). I have the PEM (pem.txt; content is enclosed with ---BEGIN/END CMS---). This is what I call the signature and I would expect to have a hash of my original file somewhere inside of it. If I do openssl rsautl -pubin -raw -encrypt -inkey pubkey.txt -in pem.txt I get an error (...rsa routines:RSA_padding_add_none:data too large for key size...). Am I doing something wrong or do I have the wrong ingredients? I try to find the hashvalue that any other tool gives me when hashing the original payload (myfile.txt). Thanks Chris On 2018-03-08 17:31, Viktor Dukhovni wrote: On Mar 8, 2018, at 11:25 AM, e...@coderhacks.com wrote: # openssl cms -sign -in myfile.txt -md md5 -signer cer.txt -inkey key.txt -outform PEM > pem.txt # md5sum myfile.txt Can I expect to find the md5sum checksum somewhere in the ASN1 of pem.txt??? # openssl asn1parse -in pem.txt As far I see it is not there - but maybe it is just a quick step to it? When signing, the checksum is part of the signature, so you'd have to decrypt the signature block with the signer's public key via: openssl rsautl -pubin -raw -encrypt -inkey pubkey.pem and find the message digest there. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Vanilla OpenSSL uses sytems libs
Hi! I put a vanilla OpenSSL in a local folder and compiled it. ./config no-shared make I will not do a "make install" because I will keep my distros installation. But Iwill use the vanilla for tests. So I need the binary as well as the libs. After a ldd I see that the apps/openssl as well as the libssl and libcrypto use the systems OpenSSL-libs instead of the one I just compiled. Is there an option so the makefile will produce binaries out of its own libs instead of the sytems? Thanks! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Vanilla OpenSSL uses sytems libs
Thanks! It works if I export LD_LIBRARY_PATH=/my/openssl/root and recompile it. On 2018-03-14 00:02, Scott Neugroschl wrote: Set LD_LIBRARY_PATH to use your compiled versions. -Original Message- From: openssl-users On Behalf Of e...@coderhacks.com Sent: Tuesday, March 13, 2018 3:46 PM To: openssl-users@openssl.org Subject: [openssl-users] Vanilla OpenSSL uses sytems libs Hi! I put a vanilla OpenSSL in a local folder and compiled it. ./config no-shared make I will not do a "make install" because I will keep my distros installation. But Iwill use the vanilla for tests. So I need the binary as well as the libs. After a ldd I see that the apps/openssl as well as the libssl and libcrypto use the systems OpenSSL-libs instead of the one I just compiled. Is there an option so the makefile will produce binaries out of its own libs instead of the sytems? 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] MIME-canonicalization
Hi! I am facing some problems with a SMIME where the content is binary encoded AND a linefeed (LF) (0x0a) is used for line-separator. The CMS_verify failes (CMS routines:CMS_SignerInfo_verify_content:verification failure). It works fine if CRLF (0x0d 0x0a) is line-separator or even if only CR is used - but not with LF only. It is also ok if the content is not in binary but base64 encoded. I tried with and without CMS_BINARY flag set. I think it is about the canonicalization of MIME if the content is not base64. Is OpenSSL doing this canonicalization (where?). I think CMS_BINARY should disable it - I tried to change any LF to CRLF before the verify but that did not help. Any ideas? Thanks! Chris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] MIME-canonicalization
I think I found the reason for the problem. SMIME_read_CMS does convert any single LF to a CRLF. If I compare the input to the CMS I get out of SMIME_read_CMS then there are all LFs replaced with CRLFs. Thats the problem with the verify. If I manually replace the added CRs in the CMS and then give it to CMS_verify all is fine. So... can I disable this canonicalization in SMIME_read_CMS?? Thanks for help! On 2018-03-14 07:43, e...@coderhacks.com wrote: Hi! I am facing some problems with a SMIME where the content is binary encoded AND a linefeed (LF) (0x0a) is used for line-separator. The CMS_verify failes (CMS routines:CMS_SignerInfo_verify_content:verification failure). It works fine if CRLF (0x0d 0x0a) is line-separator or even if only CR is used - but not with LF only. It is also ok if the content is not in binary but base64 encoded. I tried with and without CMS_BINARY flag set. I think it is about the canonicalization of MIME if the content is not base64. Is OpenSSL doing this canonicalization (where?). I think CMS_BINARY should disable it - I tried to change any LF to CRLF before the verify but that did not help. Any ideas? Thanks! Chris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Vanilla OpenSSL uses sytems libs
Yes... thats the same what I thought. I expected to link against the the vanilla built if I set no-shared. But it links against my systems libs. It seems config takes my no-shared correctly - because If I do a typo it will tell me about an unknown option. Only If I set LD_LIBRARY_PATH to my vanillas path then it links against the just built libs. Are there more parameters than no-shared that influence that?? Thanks! Chris On 2018-03-14 10:54, Richard Levitte wrote: Something here makes no sense at all... you configure with 'no-shared', and then get an apps/openssl that's linked with the system shared libraries? In message <323c64fe-c3a7-0b93-a11e-46f743b99...@coderhacks.com> on Tue, 13 Mar 2018 23:46:14 +0100, "e...@coderhacks.com" said: etc> Hi! etc> etc> I put a vanilla OpenSSL in a local folder and compiled it. etc> etc> ./config no-shared etc> make etc> etc> I will not do a "make install" because I will keep my distros etc> installation. etc> But Iwill use the vanilla for tests. So I need the binary as well as etc> the libs. etc> etc> After a ldd I see that the apps/openssl as well as the libssl and etc> libcrypto use the systems OpenSSL-libs instead of the one I just etc> compiled. etc> etc> Is there an option so the makefile will produce binaries out of its etc> own libs instead of the sytems? etc> etc> Thanks! etc> etc> etc> etc> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] MIME-canonicalization
I have verified in comparing the orginal file that is going into SIME_read_CMS with the content of the the 2nd argument (bcont) it get out of it. I check manually. The file with a hex-editor. bcont with BIO_read and then print it to the screen. The file does have LFs, the bcont does have CRLFs. The file is going directly into SMIME_read_CMS via BIO_read_filename. So I use the filename to address the content-file - no string or something with a previous parsing. I am running a debian buster. Best regards, Chris On 2018-03-14 17:25, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of e...@coderhacks.com Sent: Wednesday, March 14, 2018 02:33 To: openssl-users@openssl.org Subject: Re: [openssl-users] MIME-canonicalization I think I found the reason for the problem. SMIME_read_CMS does convert any single LF to a CRLF. Have you verified that the file actually contains bare LFs, and not CRLFs? If you're running on Windows, beware the CRLF conversions done by the C library. For example, if you write a file using a file BIO that was created using a FILE* from a text-mode fopen, that file will have LFs converted to CRLF on output. You need to open the file in binary mode, or call _setmode on the FILE* before writing to it. SMIME_read_CMS just calls SMIME_read_ASN1, which ultimately does a bunch of BIO_gets, which calls the gets method on the BIO object. A file BIO's gets method just calls fgets. So if there's translation happening, it would appear to be in the C runtime. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Vanilla OpenSSL uses sytems libs
My systems (debian 10) version is 1.1.0g. The vanilla is 1.1.0f. On 2018-03-14 23:10, Richard Levitte wrote: BTW, which OpenSSL version are we talking about here? In message on Wed, 14 Mar 2018 10:59:20 +0100, "e...@coderhacks.com" said: etc> Yes... thats the same what I thought. etc> etc> I expected to link against the the vanilla built if I set no-shared. etc> But it links against my systems libs. etc> etc> It seems config takes my no-shared correctly - because If I do a typo etc> it will tell me about an unknown option. etc> etc> Only If I set LD_LIBRARY_PATH to my vanillas path then it links etc> against the just built libs. etc> etc> Are there more parameters than no-shared that influence that?? etc> etc> Thanks! etc> Chris etc> etc> On 2018-03-14 10:54, Richard Levitte wrote: etc> > Something here makes no sense at all... you configure with etc> > 'no-shared', and then get an apps/openssl that's linked with the etc> > system shared libraries? etc> > etc> > In message <323c64fe-c3a7-0b93-a11e-46f743b99...@coderhacks.com> on etc> > Tue, 13 Mar 2018 23:46:14 +0100, "e...@coderhacks.com" etc> > said: etc> > etc> > etc> Hi! etc> > etc> etc> > etc> I put a vanilla OpenSSL in a local folder and compiled it. etc> > etc> etc> > etc> ./config no-shared etc> > etc> make etc> > etc> etc> > etc> I will not do a "make install" because I will keep my distros etc> > etc> installation. etc> > etc> But Iwill use the vanilla for tests. So I need the binary as well etc> > as etc> > etc> the libs. etc> > etc> etc> > etc> After a ldd I see that the apps/openssl as well as the libssl etc> > and etc> > etc> libcrypto use the systems OpenSSL-libs instead of the one I just etc> > etc> compiled. etc> > etc> etc> > etc> Is there an option so the makefile will produce binaries out of etc> > its etc> > etc> own libs instead of the sytems? etc> > etc> etc> > etc> Thanks! etc> > etc> etc> > etc> etc> > etc> etc> > etc> etc> etc> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
