Re: [openssl-users] free certs: bad idea wosign/startcom/startssl/startencrypt; good alt's

[Jakob Bohm]

Please note that the below summary contains a few exaggerations.  For 
instance the duplicate serial numbers seem to have been a software bug 
that issued N certificates with the same serial on busy days, while the 
backdating seemed much less excusable.  The person posting this seems 
also to be extremely US centric in his thinking, for instance 
referencing local US standards NIST and AICPA, rather than their 
international or Asian counterparts.  There is much more balanced 
information at the URL posted by Mr. Salz.


On 26/10/2016 17:50, Johann v. Preußen wrote:

this is a re-worked report i prepared that some might find useful.*

CAUTION:* there are several seriously troubling events surrounding 
WoSign *^1 * (AKA startcom, AKA startssl, and AKA startencrypt) and 
any of their affiliated/subsidiary businesses:


 1. wosign purchased startcom/startssl/startencrypt [DBA's of 'Start
Commercial LTD' (an Israeli company); hereinafter '*startcom*']
last year. although obfuscation by the parties makes determining
the actual control-transfer date impossible, the change-over may
have begun in 2014. both companies long completely and publicly
denied any change of control even as late as 2016.JUL despite it
being a matter of public record that:
 1.  the entire stock issuance from 15 startcom shareholders
including founder Revital (AKA 'Eddy') Nigg's majority
ownership was transferred in 2015.NOV;
 2.  beneficiary of the stock deal was 'StartCom CA Limited' a UK
company (09744347);
 3.  the UK company is wholly-owned by 'StartCom CA Limited' (yes,
exactly the same name again) a Hong Kong company (CRN 2271553)
with a sole director being Wang *^1 *; and
 4.  the Hong Kong entity is then owned by wosign.
 2. in fact, to-date neither firm has actually admitted what has
happened re transfer of control, domiciling of operations, and
changes in management personnel. this reticence is despite some
aspects of the transactions becoming common knowledge in the
security community;
 3. wosign attempted (rather poorly it turned out) to make it appear
that wosign was actually a subsidiary of startcom and startcom's
remnant personnel and former shareholders abetted this *^2 *;
 4. startcom is an Israeli company and -- as one would expect -- was
subjected to strict auditing and monitoring by the Israeli
government to the benefit of all the recipients of their certs ...
until the ownership change that is;
 5. wosign is a mainland Chinese (PRC) company which completely
controls startcom operations in IL, UK, CN, and US;
 6. earlier this year and last wosign -- amongst other deceptive
actions --  tried to circumvent certain mandated changes to
certificate authority (CA) practice by back-/forward-dating certs
and issuing certs with duplicate serial numbers while their CA
compliance auditors Ernst and Young (Hong Kong) were complicit in
covering up these and other forbidden practices *^3 *;
 7. in response to all these discoveries, mozilla's firefox version 51
and all look-alikes using their gecko engine have stopped
accepting any new (issued on/after 2016.OCT.21) certs that trace
back to wosign/startcom/startssl/startencrypt
root/intermediate/cross-signed certs and have banned Hong Kong
Ernst and Young CPA's from certifying any CA audits;
 8. unless wosign and its subsidiaries come up with new root
certificates and provide acceptable audit results for their
CP/CPS/operations by 2017.MAR, all of wosign-affiliated
root/intermediate/cross-signed certs will be removed from
mozilla's certificate store; and
 9. mozilla has stated that if it detects any further fraud such as
exhibited in Item 6, /supra/, all security updates to all its
software versions will immediately remove wosign-based "trusted"
certs from the mozilla root certificate store on the device being
updated which will cause the universe of wosign-issued certs to
become un-trusted in the mozilla browser family no matter when
they were issued.

*OBVIOUS CONCLUSION: *do not just walk away from wosign, startcom, 
qihoo, et alii but *RUN! *i can think of nothing worse than trusting a 
PRC firm with my sites' security. OK, if that hyperbole is not enough, 
try my personal idea of what should be network no-go and it pretty 
much lies in the swath West of Japan and East of Germany.


*THE ALTERNATIVE: *the immediate free cert replacement avenue is 
through letsencrypt.org that uses the cert issuance/renewal protocol 
ACME. although letsencrypt will not be found in most (if any) browser 
"trusted" root certificate stores, they use cross-signed intermediate 
CA certs from a root that is. there are an ever-growing number of 
open-source scripts (bash, perl, python, go, ...) available to 
automate the process which one can even customize for your particular 
needs.


there are letsencrypt p

Re: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL client

[Jakob Bohm]

On 27/10/2016 00:48, Matt Caswell wrote:

On 26/10/16 21:06, Michael Kocum wrote:

1.1.0b fails to negotiate from an old program that uses OpenSSL.
The same old program can connect to 1.0.2h without any problem.

Here is the debug log of the server. Maybe someone can point me in the right 
direction what the problem might be.

openssl s_server -debug -state -bugs -serverpref -tlsextdebug -accept 25 -cert 
selfsigned.pem
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
 - 80 c8 01 03 01.
read from 0x14fffe0 [0x1509b58] (197 bytes => 197 (0xC5))
 - 00 9f 00 00 00 20 00 c0-14 00 c0 0a 00 00 39 00   . 9.
0010 - 00 38 00 c0 0f 00 c0 05-00 00 35 00 00 88 00 00   .85.
0020 - 87 00 00 84 00 c0 12 00-c0 08 00 00 16 00 00 13   
0030 - 00 c0 0d 00 c0 03 00 00-0a 07 00 c0 00 c0 13 00   
0040 - c0 09 00 00 33 00 00 32-00 c0 0e 00 c0 04 00 00   3..2
0050 - 2f 00 00 9a 00 00 99 00-00 45 00 00 44 00 00 96   /E..D...
0060 - 00 00 41 00 00 07 05 00-80 03 00 80 00 c0 11 00   ..A.
0070 - c0 07 00 c0 0c 00 c0 02-00 00 05 00 00 04 01 00   
0080 - 80 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14   @...
0090 - 00 00 11 00 00 08 00 00-06 04 00 80 00 00 03 02   
00a0 - 00 80 00 00 ff 30 16 85-97 e0 9f e3 aa b1 07 47   .0.G
00b0 - 99 a5 7c 38 20 cd 51 39-a1 14 2f 60 50 87 26 62   ..|8 .Q9../`P.&b
00c0 - 0e c8 73 53 86..sS.

The above indicates that the client has sent an SSLv2 Compatible
ClientHello, although has indicated support for TLSv1.0. OpenSSL 1.1.0
doesn't support SSLv2, but it *does* still support the (very old) SSLv2
Compat ClientHello format. Unfortunately an SSLv2 compat hello does
*not* have an extensions section, which is important for communicating
info such as supported curves etc when using EC based ciphersuites.



SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write certificate
SSL_accept:SSLv3/TLS write key exchange
write to 0x14fffe0 [0x1512d58] (1281 bytes => 1281 (0x501))
 - 16 03 01 00 51 02 00 00-4d 03 01 2c 21 40 97 a5   Q...M..,!@..
0010 - 67 b2 a4 a7 63 cc f0 58-af 24 a4 ca 61 d8 fa bf   g...c..X.$..a...
0020 - a8 50 84 29 20 54 70 1e-f5 8e c2 20 bf ad ba d7   .P.) Tp 
0030 - fa 23 5b 77 eb 0f 30 a2-49 61 f9 ca 9f 28 3f 14   .#[w..0.Ia...(?.
0040 - bb d7 cd cf 5c 1b 69 d8-6b db 0e f7 c0 14 00 00   \.i.k...
0050 - 05 ff 01 00 01 00

This is the ServerHello that the server is sending back to the client.
The "c0 14" near the end of line 0040 indicates that the server has
selected TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as the ciphersuite.



  16 03-01 03 6e 0b 00 03 6a 00   ..n...j.
0060 - 03 67 00 03 64 30 82 03-60 30 82 02 48 02 09 00   .g..d0..`0..H...

...snip...lots of uninteresting lines

This is Certificate message sent from server to client.



   16 03 01 01 2a 0c 00   .8...*..
03d0 - 01 26 03 00 1d 20 4f b4-34 86 a8 a0 0a 45 5b 80   .&... O.4E[.
03e0 - b0 79 9e bf 4b 91 ed ae-2c b7 ee 64 ff 39 78 c8   .y..K...,..d.9x.
03f0 - a0 e7 37 e6 a5 13 01 00-1a 9f 48 8e 91 73 55 3e   ..7...H..sU>
0400 - 86 16 04 7e a9 b2 49 16-d6 f6 b3 c2 17 d1 4e 11   ...~..I...N.
0410 - c4 67 7c 81 e6 49 a2 04-d7 bc 42 04 8c 2a 0f da   .g|..IB..*..
0420 - a0 75 7d 80 98 5b 1a 0f-e2 48 55 06 95 38 0d a6   .u}..[...HU..8..
0430 - 84 f0 42 37 6b ee ca e9-e5 7e 13 11 d7 f9 3e f4   ..B7k~>.
0440 - b2 ae f1 01 e6 56 ab 7b-46 3b bd 66 de aa ad d7   .V.{F;.f
0450 - 41 59 2b 80 2d 76 98 a0-82 c8 d1 00 05 e8 11 da   AY+.-v..
0460 - c3 4b c5 15 23 c0 ba 66-8c 9b fc 80 33 c4 e8 f9   .K..#..f3...
0470 - 1f c7 82 ba b1 58 0c 87-54 42 b4 ce ed 66 4e 4e   .X..TB...fNN
0480 - 3e 51 d4 9f 5f 1e 20 18-b1 5e 6a b9 bb e7 6c b2   >Q.._. ..^j...l.
0490 - 2d 27 52 90 70 9f b0 97-cb 6d 23 0b 9d 1c e6 9d   -'R.pm#.
04a0 - 71 2a ab 9b a9 42 c9 16-ce a1 86 63 96 fe b2 b6   q*...B.c
04b0 - 49 69 5c 80 7b 9d 3d 40-a8 4a 70 51 0a a1 99 a8   Ii\.{.=@.JpQ
04c0 - b8 72 52 39 6b 8c c6 91-13 36 fb d5 fe 7d 2b db   .rR9k6...}+.
04d0 - 45 3d 73 d9 be de fd 40-19 ed ec 41 84 d5 17 a7   E=s@...A
04e0 - 6e 32 05 51 5b e6 56 44-40 2b e8 54 d9 36 cc bb   n2.Q[.VD@+.T.6..
04f0 - 77 17 cd f3 7c e7 00 60-

This is the ServerKeyExchange

The "00 1d" on line 03d0 tells you the curve that the server has
selected. That corresponds to Curve 25519 This is a modern curve
which an old client will not understand. The server has selected it
because it didn't get an extension from the client saying what curves it
supports, so it just picked one.

This is very likely to be your problem. To test the theory, try addi

[openssl-users] EVP_aes_256_wrap() in FIPS-140 mode?

[Surendar Chandra]

I cannot seem to use EVP_aes_256_wrap() in FIPS mode. I saw some earlier 
discussions on using low level APIs; but I am using the EVP method. Is it 
supported? I am using 1.0.2h/2.0.12.

Thanks much
-S
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL client

[Salz, Rich]

> More generally, I have found that it is often useful to heuristically adjust
> server side negotiation options based on clues found in the initial handshake

YES!

See https://github.com/openssl/openssl/pull/1597

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help

[Lander Bulckaen]

Dear Dmitry,



The result must be as mentionned below?



Van: openssl-users [mailto:openssl-users-boun...@openssl.org] Namens Dmitry 
Belyavsky
Verzonden: donderdag 27 oktober 2016 19:09
Aan: openssl-users@openssl.org
Onderwerp: Re: [openssl-users] Help



Hello

You should use the XMLSec library and the corresponding command-line tool.



On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen 
mailto:lan...@fit.be>> wrote:

   Hy,



   Goal: add an xml file as attachment to a MIME message and sign the MIME 
message with the primary key (.p12 file).



   The result must be like what you see below…?



   Which openssl commands must I use in commandline?

   (I already searched for ita bout 2 months but still not found any solution…!)



   Date: Fri Jul 01 10:26:15 CEST 2016

   From: michel.domb...@nbb.be

   To:

   Message-ID: 
<28456974.01467361575985.JavaMail.feronan@PC0020881>

   Subject: NBB signed file

   MIME-Version: 1.0

   Content-Type: multipart/signed;

   boundary="=_Part_1_6142443.1467361575963";

   protocol="application/pkcs7-signature"; micalg=sha1



   --=_Part_1_6142443.1467361575963

   Content-Type: multipart/mixed;

   boundary="=_Part_0_25389802.1467361575861"



   --=_Part_0_25389802.1467361575861

   Content-Type: text/plain; charset=us-ascii

   Content-Transfer-Encoding: 7bit



   Message created by Offline Signing Tool of National bank of BELGIUM

   --=_Part_0_25389802.1467361575861

   Content-Type: application/octet-stream; name=RequestFeedbacks.xml

   Content-Transfer-Encoding: 7bit

   Content-Disposition: attachment; filename=RequestFeedbacks.xml



   

   

   V01

   

   

   2016-08-01

   2016-08-15

   

   ALL

   true

   

   



   --=_Part_0_25389802.1467361575861--



   --=_Part_1_6142443.1467361575963

   Content-Type: application/pkcs7-signature; name=smime.p7s

   Content-Transfer-Encoding: base64

   Content-Disposition: attachment; filename=smime.p7s



   MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBXMw

   ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1

   c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp

   dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy

   ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0wNzA0MDMxMzE2MDRa

   Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV

   BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xCzAJBgNVBAsT

   AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkBFhNwcjAzaGtldHRp

   bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXENutQ5VnJDP0Q1waji

   85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b6d/ErcVBweBORvRo

   MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+pEkCdxM3ELZRZM6Rp

   7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/1sOuga0jf80sNpuQm9hysHRG

   fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUmwCKhbgEYjnIxQ

   71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G

   X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvVMB4GA1UdEQQXMBWB

   E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr

   BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+ADCcE5+oIz0Kts4f

   OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI+UU2QiyaUfXSMvuLct3yZX0Pc6+

   8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+762HW04TNhgQUUkMaEn/T

   HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNWSt8NsEmba/7ZD3

   XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+89MT56qfrDbfiJtRvICWXTYBh0tdki

   057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+2TyF

   BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjSlXkk0yvnF6

   vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+CzeSpmDJNtKnU/nm

   ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjoNICBKYO

   VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJKoZI

   hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1

   c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT

   ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI

   hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUxODA4NDkzMFowgbUx

   CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAfBgNV

   BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBNYW5h

   Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1kc21v

   cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+wnMwqwqr8q7m20/ly+

   

Re: [openssl-users] Help

[Dmitry Belyavsky]

Sorry, my fault.

I think you should use the openssl smime command, but it doesn't work with
PKCS12, so you will have to extract the private and public keys using the
openssl pkcs12 command.

28 окт. 2016 г. 2:34 PM пользователь "Lander Bulckaen" 
написал:

> Dear Dmitry,
>
>
>
> The result must be as mentionned below?
>
>
>
> *Van:* openssl-users [mailto:openssl-users-boun...@openssl.org] *Namens 
> *Dmitry
> Belyavsky
> *Verzonden:* donderdag 27 oktober 2016 19:09
> *Aan:* openssl-users@openssl.org
> *Onderwerp:* Re: [openssl-users] Help
>
>
>
> Hello
>
> You should use the XMLSec library and the corresponding command-line tool.
>
>
>
> On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen  wrote:
>
> Hy,
>
>
>
> Goal: add an xml file as attachment to a MIME message and *sign the MIME
> message* with the primary key (.p12 file).
>
>
>
> The result must be like what you see below…?
>
>
>
> Which openssl commands must I use in commandline?
>
> (I already searched for ita bout 2 months but still not found any
> solution…!)
>
>
>
> Date: Fri Jul 01 10:26:15 CEST 2016
>
> From: michel.domb...@nbb.be
>
> To:
>
> Message-ID: <28456974.01467361575985.JavaMail.feronan@PC0020881>
>
> Subject: NBB signed file
>
> MIME-Version: 1.0
>
> Content-Type: multipart/signed;
>
> boundary="=_Part_1_6142443.1467361575963";
>
> protocol="application/pkcs7-signature"; micalg=sha1
>
>
>
> --=_Part_1_6142443.1467361575963
>
> Content-Type: multipart/mixed;
>
> boundary="=_Part_0_25389802.1467361575861"
>
>
>
> --=_Part_0_25389802.1467361575861
>
> Content-Type: text/plain; charset=us-ascii
>
> Content-Transfer-Encoding: 7bit
>
>
>
> Message created by Offline Signing Tool of National bank of BELGIUM
>
> --=_Part_0_25389802.1467361575861
>
> Content-Type: application/octet-stream; name=RequestFeedbacks.xml
>
> Content-Transfer-Encoding: 7bit
>
> Content-Disposition: attachment; filename=RequestFeedbacks.xml
>
>
>
> 
>
> 
>
> V01
>
> 
>
> 
>
> 2016-08-01
>
> 2016-08-15
>
> 
>
> ALL
>
> true
>
> 
>
> 
>
>
>
> --=_Part_0_25389802.1467361575861--
>
>
>
> --=_Part_1_6142443.1467361575963
>
> Content-Type: application/pkcs7-signature; name=smime.p7s
>
> Content-Transfer-Encoding: base64
>
> Content-Disposition: attachment; filename=smime.p7s
>
>
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
> AQAAoIIMtzCCBXMw
>
> ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTER
> MA8GA1UECBMIQnJ1
>
> c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBC
> YW5rIG9mIEJlbGdp
>
> dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UE
> AxMTTkJCIFNlY3Vy
>
> ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0w
> NzA0MDMxMzE2MDRa
>
> Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
> c3NlbHMxETAPBgNV
>
> BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
> dW0xCzAJBgNVBAsT
>
> AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkB
> FhNwcjAzaGtldHRp
>
> bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXEN
> utQ5VnJDP0Q1waji
>
> 85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b
> 6d/ErcVBweBORvRo
>
> MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+
> pEkCdxM3ELZRZM6Rp
>
> 7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/
> 1sOuga0jf80sNpuQm9hysHRG
>
> fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUm
> wCKhbgEYjnIxQ
>
> 71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/
> wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
>
> X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvV
> MB4GA1UdEQQXMBWB
>
> E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQG
> CCsGAQUFBwMCBggr
>
> BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+
> ADCcE5+oIz0Kts4f
>
> OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI
> +UU2QiyaUfXSMvuLct3yZX0Pc6+
>
> 8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+
> 762HW04TNhgQUUkMaEn/T
>
> HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNW
> St8NsEmba/7ZD3
>
> XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+
> 89MT56qfrDbfiJtRvICWXTYBh0tdki
>
> 057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+
> 2TyF
>
> BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjS
> lXkk0yvnF6
>
> vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+
> CzeSpmDJNtKnU/nm
>
> ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjo
> NICBKYO
>
> VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJ
> KoZI
>
> hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczER
> MA8GA1UEBxMIQnJ1
>
> c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8G
> A1UECxMYRGF0YSBT
>
> ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWls
> IENBMRwwGgYJKoZI
>
> hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUx
> ODA4NDkzMFowgbUx
>
> CzAJBgNVBAYTAkJFM

Re: [openssl-users] Help

[Lander Bulckaen]

Dear,

Yes I know.

I already extracted both keys from the .p12 file.

My biggest problem is how you can add the original file (in this case 
‘RequestFeedbacks.xml’) as attachment? (the signature ‘smime.p7s’ is already 
attached)

Thanks for you quick reply and support!

Kind regards,
Lander

Van: openssl-users [mailto:openssl-users-boun...@openssl.org] Namens Dmitry 
Belyavsky
Verzonden: vrijdag 28 oktober 2016 14:52
Aan: openssl-users@openssl.org
Onderwerp: Re: [openssl-users] Help


Sorry, my fault.

I think you should use the openssl smime command, but it doesn't work with 
PKCS12, so you will have to extract the private and public keys using the 
openssl pkcs12 command.

28 окт. 2016 г. 2:34 PM пользователь "Lander Bulckaen" 
mailto:lan...@fit.be>> написал:
Dear Dmitry,

The result must be as mentionned below?

Van: openssl-users 
[mailto:openssl-users-boun...@openssl.org]
 Namens Dmitry Belyavsky
Verzonden: donderdag 27 oktober 2016 19:09
Aan: openssl-users@openssl.org
Onderwerp: Re: [openssl-users] Help

Hello
You should use the XMLSec library and the corresponding command-line tool.

On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen 
mailto:lan...@fit.be>> wrote:
Hy,

Goal: add an xml file as attachment to a MIME message and sign the MIME message 
with the primary key (.p12 file).

The result must be like what you see below…?

Which openssl commands must I use in commandline?
(I already searched for ita bout 2 months but still not found any solution…!)

Date: Fri Jul 01 10:26:15 CEST 2016
From: michel.domb...@nbb.be
To:
Message-ID: 
<28456974.01467361575985.JavaMail.feronan@PC0020881>
Subject: NBB signed file
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="=_Part_1_6142443.1467361575963";
protocol="application/pkcs7-signature"; micalg=sha1

--=_Part_1_6142443.1467361575963
Content-Type: multipart/mixed;
boundary="=_Part_0_25389802.1467361575861"

--=_Part_0_25389802.1467361575861
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Message created by Offline Signing Tool of National bank of BELGIUM
--=_Part_0_25389802.1467361575861
Content-Type: application/octet-stream; name=RequestFeedbacks.xml
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=RequestFeedbacks.xml



V01


2016-08-01
2016-08-15

ALL
true



--=_Part_0_25389802.1467361575861--

--=_Part_1_6142443.1467361575963
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBXMw
ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy
ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0wNzA0MDMxMzE2MDRa
Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xCzAJBgNVBAsT
AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkBFhNwcjAzaGtldHRp
bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXENutQ5VnJDP0Q1waji
85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b6d/ErcVBweBORvRo
MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+pEkCdxM3ELZRZM6Rp
7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/1sOuga0jf80sNpuQm9hysHRG
fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUmwCKhbgEYjnIxQ
71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvVMB4GA1UdEQQXMBWB
E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+ADCcE5+oIz0Kts4f
OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI+UU2QiyaUfXSMvuLct3yZX0Pc6+
8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+762HW04TNhgQUUkMaEn/T
HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNWSt8NsEmba/7ZD3
XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+89MT56qfrDbfiJtRvICWXTYBh0tdki
057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+2TyF
BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjSlXkk0yvnF6
vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+CzeSpmDJNtKnU/nm
ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjoNICBKYO
VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJKoZI
hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
c3NlbHMxITAfBgNVB

[openssl-users] Fwd: osf-contact SignatureValue

[Hugo N.Barretto]

-- Forwarded message --
From: Salz, Rich 
Date: Thu, Oct 27, 2016 at 10:27 PM
Subject: RE: osf-contact SignatureValue
To: "Hugo N.Barretto" , "i...@opensslfoundation.org"



Probably more useful to ask your questions on the openssl-users mailing
list; see https://mta.openssl.org



--

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richs...@jabber.at Twitter: RichSalz



*From:* Hugo N.Barretto [mailto:hugobarre...@gmail.com]
*Sent:* Thursday, October 27, 2016 7:45 PM
*To:* i...@opensslfoundation.org
*Subject:* osf-contact SignatureValue



Hi!. Mr/Mrs.



Please I'd like to elimnate a great doubt mine. I'm for a long time trying
urderstand how openssl works on browser, but yet i do not find out it.



I know calculate digestValue and also encrypt in base64, then i obtain my
desired result in command line inside the prompt.



Is there some way to get this value, executing this commands through do
browser? Using JavaScript for example?



If possible send to me some light that open my mind to solve this problem!!
Thank so much. Hugo.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Cannot initialize FIPS library in 1.0.2j but 1.0.2i is OK

[Perrow, Graeme]

I'm seeing a problem where my application cannot initialize the FIPS library 
(i.e. the call to FIPS_mode_set fails) when using 1.0.2j libraries. The error I 
get is: "FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232:" 
However if I build 1.0.2i libraries, everything is fine. I am using the same 
script to build both versions, and completely wiping the directories and 
re-creating from the .tar.gz files each time.

The weirdest thing is that if I build my application for 1.0.2i but replace 
1.0.2i with the 1.0.2j code (just modifying the version number in the header 
files), everything works. If I build it for 1.0.2j but actually use 1.0.2i 
(again just changing the version number), it fails.

This is on 64-bit Linux. Other platforms (32-bit and 64-bit Windows, 32-bit 
Linux, Solaris, HP) are all working fine.

This seems to be a problem with *my* code but I have no idea how I could 
possibly cause this to happen. Any ideas?

Graeme

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users