[openssl-users] Money

[Hello Notelling]

I need a way to gain lots of money fast so could you hook me up with some
one that's seeking gold as i will happily distribute through the country
legally and illegally
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL_set_verify with a context?

[Ryan Pfeifle]

You can use X509_STORE_CTX_get_app_data() and type-cast the returned pointer to 
SSL*.





Ryan Pfeifle
Software Engineer

[cid:2cada4cd821843daa7153d792a28ea74]
VPI is now part of NICE


Tel: 1.805.389.5200 x5297


E-mail: ryan.pfei...@nice.com






The information transmitted in this message is intended only for the addressee 
and may contain confidential and/or privileged material. If you received this 
in error, please contact the sender and delete this material from any computer.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Lei 
Kong
Sent: Thursday, October 27, 2016 11:54 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] SSL_set_verify with a context?

I am using the following link ssl to my container structure, so is it possible 
to  get ssl from x509_ctx in verify_callback?
SSL_set_app_data(ssl, this);

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);


From: Lei Kong mailto:leik...@msn.com>>
Sent: Thursday, October 27, 2016 1:24:05 AM
To: openssl-users@openssl.org
Subject: SSL_set_verify with a context?


What I am trying to achieve is to allow some minor certificate chain validation 
errors, e.g. "CRL unavailable", based on my per-session configuration. I am 
think of using my verify callback to record the errors.

void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, 
X509_STORE_CTX *));

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);



Given the above interfaces, it seems I cannot set the callback with a context, 
which is needed to link a callback instance to my SSL session for error 
tracking. Yes, I can use SSL_get_verify_result to get the error afterwards, but 
is it guaranteed that the most severe error is always returned by 
SSL_get_verify_result? For example, I don't want "unable to get CRL" to mask 
other more important errors.



I would rather avoid repeating validating the whole chain manually after 
default validation is completed, is it possible to achieve my goal without 
repeating chain validation manually?



Any comment will be appreciated.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL_set_verify with a context?

[Lei Kong]

I am using the following link ssl to my container structure, so is it possible 
to  get ssl from x509_ctx in verify_callback?
SSL_set_app_data(ssl, this);

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);



From: Lei Kong 
Sent: Thursday, October 27, 2016 1:24:05 AM
To: openssl-users@openssl.org
Subject: SSL_set_verify with a context?


What I am trying to achieve is to allow some minor certificate chain validation 
errors, e.g. "CRL unavailable", based on my per-session configuration. I am 
think of using my verify callback to record the errors.

void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, 
X509_STORE_CTX *));

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);


Given the above interfaces, it seems I cannot set the callback with a context, 
which is needed to link a callback instance to my SSL session for error 
tracking. Yes, I can use SSL_get_verify_result to get the error afterwards, but 
is it guaranteed that the most severe error is always returned by 
SSL_get_verify_result? For example, I don't want "unable to get CRL" to mask 
other more important errors.


I would rather avoid repeating validating the whole chain manually after 
default validation is completed, is it possible to achieve my goal without 
repeating chain validation manually?


Any comment will be appreciated.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help

[Dmitry Belyavsky]

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
>
> CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
> c3NlbHMxITAfBgNV
>
> BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT
> ZWN1cml0eSBNYW5h
>
> Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI
> hvcNAQkBFg1kc21v
>
> cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+
> wnMwqwqr8q7m20/ly+
>
> HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+
> RKElWRTc06z8sqisHL282hULh/G
>
> Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjx
> qs22jEd0ibOs
>
> vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N
> 8Zi9+lAslkxsgDe

[openssl-users] Help

[Lander Bulckaen]

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+
HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+RKElWRTc06z8sqisHL282hULh/G
Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjxqs22jEd0ibOs
vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N8Zi9+lAslkxsgDen
txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM0sw4fcETkDQ
AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/gRDrL++NeDiJ38JUyK+
nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+ZNITy6iOkUdXLgGdvS1YVa3
SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PHnk7dsHBIvvHLQt3A
Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieFstA4I3bzYLFwALirTFuR1SRH/9xl3s
6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUswggFHMB0G
A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21vcHNAbmJiLmJlMA8G
A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/GX75S00GfLLk

Re: [openssl-users] Enabling FIPS on an custom embedded system.

[Steve Marquess]

On 10/26/2016 06:06 PM, Eric Tremblay wrote:
> Hi Steve,
> 
> Thanks for the quick reply.
> 
> That is what I had understand from my reading but wasn't sure.
> 
> My next question is about OpenSSH.  There is no official support in
> OpenSSH for FIPS at the moment right ?
> 
> Thanks
> 
> Eric
> 

No, and there never will be; as I understand it the OpenSSH project has
taken the position that FIPS 140 isn't a desirable feature for OpenSSH.
TBH they have a point; from any technical perspective (e.g. security,
performance, maintainability) FIPS support is a negative. Ditto x.509
where the OpenSSH project has implemented a much simpler and more robust
certificate scheme.

You can find a rather old patch at
http://openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch, but
note that OpenSSH has evolved considerably since then.

There is another issue to consider as well. The only sane reason to use
FIPS 140 validated software is for deployment in environments where such
validation is a mandatory policy requirement. The US DoD is the largest
such environment, and there x.509 is also a mandate. Roumen Petrov has
for years maintained patches to add x.509 support to OpenSSH
(http://roumenpetrov.info/openssh/), but hacking OpenSSH for both FIPS
140 and x.509 is not a project for the faint-hearted, and since OpenSSH
is unlikely to ever add either feature officially you're left with a
long maintenance tail.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
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] SSL_set_verify with a context?

[Lei Kong]

What I am trying to achieve is to allow some minor certificate chain validation 
errors, e.g. "CRL unavailable", based on my per-session configuration. I am 
think of using my verify callback to record the errors.

void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, 
X509_STORE_CTX *));

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);


Given the above interfaces, it seems I cannot set the callback with a context, 
which is needed to link a callback instance to my SSL session for error 
tracking. Yes, I can use SSL_get_verify_result to get the error afterwards, but 
is it guaranteed that the most severe error is always returned by 
SSL_get_verify_result? For example, I don't want "unable to get CRL" to mask 
other more important errors.


I would rather avoid repeating validating the whole chain manually after 
default validation is completed, is it possible to achieve my goal without 
repeating chain validation manually?


Any comment will be appreciated.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users