[openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine

[David Oberhollenzer]

Hi,

I'm trying to compile OpenSSL 1.1.0e with the afalg engine on a
recent CentOS 7. I removed the kernel version check for the
afalg engine from the Configure script since AFAIK the CentOS
kernel should have all of that back ported. I ran the following
configure command:

$ ./Configure linux-x86_64 shared enable-engine enable-dso \
  enable-afalgeng --prefix=/opt/openssl --openssldir=/opt/openssl


After make, I get an afalg.so in the output, but after installing
it and running openssl speed I get complaints about bind_engine
not being exported:


$ /opt/openssl/bin/openssl speed -evp aes-128-cbc -engine afalg
invalid engine "afalg"
140034190133056:error:2506406A:DSO support
routines:dlfcn_bind_func:could not bind to the requested symbol
name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine):
/opt/openssl/lib/engines-1.1/afalg.so: undefined symbol: bind_engine
140034190133056:error:2506C06A:DSO support routines:DSO_bind_func:could
not bind to the requested symbol name:crypto/dso/dso_lib.c:185:
140034190133056:error:260B6068:engine routines:dynamic_load:DSO
failure:crypto/engine/eng_dyn.c:427:
140034190133056:error:2606A074:engine routines:ENGINE_by_id:no such
engine:crypto/engine/eng_list.c:339:id=afalg
140034190133056:error:25066067:DSO support routines:dlfcn_load:could not
load the shared
library:crypto/dso/dso_dlfcn.c:113:filename(libafalg.so): libafalg.so:
cannot open shared object file: No such file or directory
140034190133056:error:25070067:DSO support routines:DSO_load:could not
load the shared library:crypto/dso/dso_lib.c:161:
140034190133056:error:260B6084:engine routines:dynamic_load:dso not
found:crypto/engine/eng_dyn.c:414:
...


Running readelf on afalg.so confirms that the symbol is indeed not
in the binary. Am I missing some magic configure options or is there
some other problem?


Thanks,

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

Re: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine

[Matt Caswell]

On 22/02/17 09:11, David Oberhollenzer wrote:
> Running readelf on afalg.so confirms that the symbol is indeed not
> in the binary. Am I missing some magic configure options or is there
> some other problem?

I just tried the exact same Configure line as you on 1.1.0e and it all
works fine:

$ readelf afalg.so -s | grep bind_engine
66: 2840   319 FUNCGLOBAL DEFAULT   12 bind_engine
95: 2840   319 FUNCGLOBAL DEFAULT   12 bind_engine


You said you:

> removed the kernel version check for the
> afalg engine from the Configure script since AFAIK the CentOS
> kernel should have all of that back ported.

There is a similar check in engines/afalg/e_afalg.c which checks the
version of the kernel headers. Did you also amend that:


#if LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2) || \
!defined(AF_ALG)
# ifndef PEDANTIC
#  warning "AFALG ENGINE requires Kernel Headers >= 4.1.0"
#  warning "Skipping Compilation of AFALG engine"
# endif
void engine_load_afalg_int(void);
void engine_load_afalg_int(void)
{
}
#else


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

Re: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine

[Richard Weinberger]

Am 22.02.2017 um 12:24 schrieb David Oberhollenzer:
> Sorry, never mind. After taking a closer look at the source code I saw
> that there are further compile time and run-time kernel version
> checks in e_afalg.c. I adjusted the version number and got that to
> work now.

Well, why does the afalg engine depend on Linux 4.1?
AF_ALG is part of Linux since 2.6.38.

Furthermore it is not clear to me why the Kernel version is being
checked during the build.
What if I build on an older kernel?
Does your build system offer a config option for that?

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL handshake failure with RSA bad signature error

[Senthil Raja Velu]

Hi,
I have recently updated my openssl server version from 1.0.1m to 1.0.2j.
After updating the handshake fails with the client. The client still use
openssl version 1.0.1e-fips.

Note: With older openssl server version (1.0.1m) the handshake works with
the same set of certificates.

Here is the complete handshake message sequence from the server side with
all debugs:

TlsInfoCB HANDSHAKE_START(time:4849) sCount(0) cCount(1)
undefined:before/accept initialization

TlsInfoCB SSL_accept:before/accept initialization

TlsMsgCB TLS-MSG: <<< ???  len=5

TlsHexDumpCB
 - 16 03 01 00 94.

TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=148  ClientHello

TlsHexDumpCB
 - 01 00 00 90 03 03 58 ad-d7 b5 64 af 9e d2 38 c4   ..X...d...8.
0010 - 4a 8b fc 7c 3b 2f 12 64-68 70 c4 57 73 54 54 ce   J..|;/.dhp.WsTT.
0020 - 82 dd f2 58 c7 85 00 00-24 00 0a 00 2f 00 32 00   ...X$.../.2.
0030 - 33 00 35 c0 14 c0 03 c0-04 c0 05 c0 08 c0 09 c0   3.5.
0040 - 0a c0 0d c0 0e c0 0f c0-12 c0 13 00 ff 01 00 00   
0050 - 43 00 0b 00 04 03 00 01-02 00 0a 00 08 00 06 00   C...
0060 - 19 00 18 00 17 00 23 00-00 00 0d 00 22 00 20 06   ..#.". .
0070 - 01 06 02 06 03 05 01 05-02 05 03 04 01 04 02 04   
0080 - 03 03 01 03 02 03 03 02-01 02 02 02 03 01 01 00   
0090 - 0f 00 01 01   

TlsExtCB TLS-EXT: client "EC point formats" (id=11) len=4

TlsHexDumpCB
 - 03 00 01 02   

TlsExtCB TLS-EXT: client "elliptic curves" (id=10) len=8

TlsHexDumpCB
 - 00 06 00 19 00 18 00 17-  

TlsExtCB TLS-EXT: client "session ticket" (id=35) len=0

TlsExtCB TLS-EXT: client "signature algorithms" (id=13) len=34

TlsHexDumpCB
 - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01   . ..
0010 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03   
0020 - 01 01 ..

TlsExtCB TLS-EXT: client "heartbeat" (id=15) len=1

TlsHexDumpCB
 - 01.

TlsInfoCB SSL_accept:SSLv3 read client hello A

TlsMsgCB TLS-MSG: >>> ???  len=5

TlsHexDumpCB
 - 16 03 03 00 3a:

TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=58  ServerHello

TlsHexDumpCB
 - 02 00 00 36 03 03 b6 97-ce 9a 96 74 98 52 c0 4a   ...6...t.R.J
0010 - c4 2e f4 20 1f 47 c0 b3-2e e4 8c ed 79 9e 22 e1   ... .G..y.".
0020 - 57 f9 1f 56 c4 b5 00 00-0a 00 00 0e ff 01 00 01   W..V
0030 - 00 00 23 00 00 00 0f 00-01 01 ..#...

TlsInfoCB SSL_accept:SSLv3 write server hello A

TlsMsgCB TLS-MSG: >>> ???  len=5

TlsHexDumpCB
 - 16 03 03 04 f1.

TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=1265  Certificate

TlsHexDumpCB
 - 0b 00 04 ed 00 04 ea 00-02 15 30 82 02 11 30 82   ..0...0.
0010 - 01 7a 02 09 00 aa f8 6d-8b 4d d8 0f f0 30 0d 06   .z.m.M...0..
0020 - 09 2a 86 48 86 f7 0d 01-01 05 05 00 30 4e 31 0b   .*.H0N1.
0030 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06   0...UUS1.0..
0040 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61   .UCalifornia
0050 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f   1.0...USanJo
0060 - 73 65 31 18 30 16 06 03-55 04 03 13 0f 77 77 77   se1.0...Uwww
0070 - 2e 6e 75 61 67 65 43 41-2e 63 6f 6d 30 1e 17 0d   .nuageCA.com0...
0080 - 31 34 30 39 30 34 30 39-35 37 35 30 5a 17 0d 32   140904095750Z..2
0090 - 34 30 39 30 31 30 39 35-37 35 30 5a 30 4c 31 0b   40901095750Z0L1.
00a0 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06   0...UUS1.0..
00b0 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61   .UCalifornia
00c0 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f   1.0...USanJo
00d0 - 73 65 31 16 30 14 06 03-55 04 03 13 0d 77 77 77   se1.0...Uwww
00e0 - 2e 6e 75 61 67 65 2e 63-6f 6d 30 81 9f 30 0d 06   .nuage.com0..0..
00f0 - 09 2a 86 48 86 f7 0d 01-01 01 05 00 03 81 8d 00   .*.H
0100 - 30 81 89 02 81 81 00 d1-2f 3b 18 80 af 87 aa f3   0.../;..
0110 - dd 62 5f 96 d6 69 ba 28-cf f6 56 7f c8 56 62 de   .b_..i.(..V..Vb.
0120 - 7a 9d fc 6d 26 17 df 0d-5f 09 15 5e 24 68 04 37   z..m&..._..^$h.7
0130 - e0 02 47 e3 18 64 5c 2e-0a 2e 89 57 f9 54 b0 97   ..G..d\W.T..
0140 - 93 24 06 8b 22 55 54 68-89 ea 8d 1d 97 b0 d2 8b   .$.."UTh
0150 - 5b 34 19 ba 41 c0 da ca-49 82 d4 76 a3 de 5f fc   [4..A...I..v.._.
0160 - cf fa 6b 22 6c 8c c9 af-c2 e4 2b 08 75 cf 3d 5a   ..k"l.+.u.=Z
0170 - eb 32 9c 23 ac 6a 09 a7-7a 7b 67 36 08 17 e0 76   .2.#.j..z{g6...v
0180 - a0 9c f5 5b dc 0a a1 02-03 01 00 01 30 0d 06 09   ...[0...
0190 - 2a 86 48 86 f7 0d 01 01-05 05 00 03 81 81 00 09   *.H.
01a0 - ef 65 ee e8 3d b9 5f 11-5c 8a 8b 97 f7 3f 75 78   .e..=._.\?ux
01b0 - f3 11 5f 09 0e b8 fe a0-6b 70 53 1e 34 1b 66 55   

Re: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine

[Matt Caswell]

On 22/02/17 20:20, Richard Weinberger wrote:
> Am 22.02.2017 um 12:24 schrieb David Oberhollenzer:
>> Sorry, never mind. After taking a closer look at the source code I saw
>> that there are further compile time and run-time kernel version
>> checks in e_afalg.c. I adjusted the version number and got that to
>> work now.
> 
> Well, why does the afalg engine depend on Linux 4.1?
> AF_ALG is part of Linux since 2.6.38.

I think its the dependence on the AIO stuff. The AFALG engine is an
async aware engine. If your application is also async aware (i.e. uses
the new async APIs in 1.1.0) then you can offload crypto work onto the
kernel while you application gets on with something else.

At the moment though the crypto support in that engine is quite limited.
It only supports offloading of AES128-CBC.

> 
> Furthermore it is not clear to me why the Kernel version is being
> checked during the build.
> What if I build on an older kernel?
> Does your build system offer a config option for that?

No - I guess the assumption is that it is more normal to do it the other
way around (i.e. build on a newer kernel but target an older one).

Matt

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

Re: [openssl-users] DTLS for SCTP connections

[Michael Tuexen]

> On 22 Feb 2017, at 07:47, mahesh gs  wrote:
> 
> Hi,
> 
> Thank you for sharing the sample code.
> 
> I tried running SCTP DTLS Echo server and client. I am facing strange problem 
> "ssl_connect" hangs on the client side, even the "ssl_accept" hangs on the 
> server side. 
> 
> Client side back trace
> 
> (gdb) bt
> #0  0x003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0
> #1  0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 
> "\026\376\377", outl=17741) at bss_dgram.c:1178
> #2  0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) at 
> bio_lib.c:210
> #3  0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, 
> extend=) at s3_pkt.c:258
> #4  0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676
> #5  0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, 
> buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938
> #6  0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70, st1= optimized out>, stn=4449, max=30, ok=0x7ffee09c)
> at d1_both.c:908
> #7  0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448, stn=4449, 
> mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512
> #8  0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at s3_clnt.c:2458
> #9  0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466
> #10 0x00402f75 in start_client(char*, char*, int, int, int) ()
> #11 0x00403573 in main ()
> 
> 
> Server side back trace
> 
> (gdb) info threads
>   2 Thread 0x7793c700 (LWP 20161)  0x003db4c0ea2d in recvmsg () from 
> /lib64/libpthread.so.0
> * 1 Thread 0x7793e720 (LWP 20155)  0x003db4c0e84d in accept () from 
> /lib64/libpthread.so.0
> (gdb) t 2
> [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0  
> 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> (gdb) bt
> #0  0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> #1  0x77a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x70001930) at 
> bss_dgram.c:1803
> #2  0x77dc7830 in dtls1_accept (s=0x78c0) at d1_srvr.c:403
> #3  0x004021ee in connection_handle(void*) ()
> #4  0x003db4c07851 in start_thread () from /lib64/libpthread.so.0
> #5  0x003db48e890d in clone () from /lib64/libc.so.6
> (gdb)
> 
> 
> I am also attaching the wireshark trace (port 4443) and a server key for 
> decoding wireshark.
> 
> Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443
> 
> Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 -l 50 
> -n 5 16.181.38.161
> 
> Thanks in advance for your valuable input
I've CCed Irene, who did some testing recently on FreeBSD, where the 
implementation works.
The server is waiting for a sender dry event which it should get.

Which version of OpenSSL are you using and which OS are you using?

Best regards
Michael
> 
> Regards,
> Mahesh G S
> 
> 
> 
> On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen 
>  wrote:
> > On 21 Feb 2017, at 09:53, mahesh gs  wrote:
> >
> > Hi,
> >
> > We have a client, server applications that is using SCTP as a transport 
> > protocol. We have to secure the connections using DTLS. I am using openssl 
> > version 1.0.2 which supports DTLS. But the problem i am facing is usage of 
> > DTLS SCTP related API's. Openssl documentation does not clearly explain all 
> > the SCTP related API's and usage sequence.
> >
> > I have tried going though internet and found most of the sites redirect to 
> > one link for SCTP DTLS sample code. But this link is not working.
> >
> > http://sctp.fh-muenster.de/dtls-samples.html
> Try
> http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html
> and yes, we need to bring the machine up again.
> 
> Best regards
> Michael
> >
> > If any of you has an sample code of DTLS adaptation for SCTP. It would 
> > immensely help me for my work.
> >
> > Looking forward to your valuable inputs.
> >
> > Thanks,
> > Mahesh G S
> > --
> > 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] Compiling OpenSSL 1.1.0e with AF_ALG engine

[Jeffrey Walton]

>> Sorry, never mind. After taking a closer look at the source code I saw
>> that there are further compile time and run-time kernel version
>> checks in e_afalg.c. I adjusted the version number and got that to
>> work now.
>
> Well, why does the afalg engine depend on Linux 4.1?
> AF_ALG is part of Linux since 2.6.38.
>
> Furthermore it is not clear to me why the Kernel version is being
> checked during the build.
> What if I build on an older kernel?
> Does your build system offer a config option for that?

Also see https://mta.openssl.org/pipermail/openssl-dev/2016-March/006171.html

Its been my experience that most AFALG issues are due to the kernel
and problems with its implementation, and not OpenSSL.

Kernel test vectors are virtually non-existent, so things randomly
move in and out of a state of "it works as expected" to other various
states. For example, here are the AFALG test vectors:
https://github.com/tstruk/afalg_async_test. They are not in the kernel
proper, they are incomplete, and its hits or miss whether they will
work as expected.

You can learn if an async driver is available with:

   cat /proc/crypto | egrep '^(name|driver|async|$)'

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

Re: [openssl-users] DTLS for SCTP connections

[mahesh gs]

Hi Michael,

I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and
openssl version is 1.1.0.

SCTP version :

[root@localhost DIAMETER]# rpm -qa | grep -i "sctp"
*lksctp-tools-1.0.10-5.el6.x86_64*
[root@localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64
Name: lksctp-tools Relocations: (not relocatable)
Version : 1.0.10Vendor: Red Hat, Inc.
Release : 5.el6 *Build Date: Mon 22 Feb 2010
12:24:33 PM CET*
Install Date: Wed 08 Feb 2017 10:08:12 AM CET  Build Host:
hs20-bc1-2.build.redhat.com
Group   : System Environment/Libraries   Source RPM:
lksctp-tools-1.0.10-5.el6.src.rpm
Size: 203688   License: GPLv2 and GPLv2+
and LGPLv2 and BSD
Signature   : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID
199e2f91fd431d51
Packager: Red Hat, Inc. 
URL : http://lksctp.sourceforge.net
Summary : User-space access to Linux Kernel SCTP
Description :
This is the lksctp-tools package for Linux Kernel SCTP (Stream Control
Transmission Protocol) Reference Implementation.



Thanks,
Mahesh G S

On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen <
michael.tue...@lurchi.franken.de> wrote:

> > On 22 Feb 2017, at 07:47, mahesh gs  wrote:
> >
> > Hi,
> >
> > Thank you for sharing the sample code.
> >
> > I tried running SCTP DTLS Echo server and client. I am facing strange
> problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs
> on the server side.
> >
> > Client side back trace
> >
> > (gdb) bt
> > #0  0x003db4c0ea10 in __recvmsg_nocancel () from
> /lib64/libpthread.so.0
> > #1  0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073
> "\026\376\377", outl=17741) at bss_dgram.c:1178
> > #2  0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073,
> outl=17741) at bio_lib.c:210
> > #3  0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741,
> extend=) at s3_pkt.c:258
> > #4  0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676
> > #5  0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22,
> buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938
> > #6  0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70,
> st1=, stn=4449, max=30, ok=0x7ffee09c)
> > at d1_both.c:908
> > #7  0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448,
> stn=4449, mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512
> > #8  0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at
> s3_clnt.c:2458
> > #9  0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466
> > #10 0x00402f75 in start_client(char*, char*, int, int, int) ()
> > #11 0x00403573 in main ()
> >
> >
> > Server side back trace
> >
> > (gdb) info threads
> >   2 Thread 0x7793c700 (LWP 20161)  0x003db4c0ea2d in recvmsg ()
> from /lib64/libpthread.so.0
> > * 1 Thread 0x7793e720 (LWP 20155)  0x003db4c0e84d in accept ()
> from /lib64/libpthread.so.0
> > (gdb) t 2
> > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0
> 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> > (gdb) bt
> > #0  0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> > #1  0x77a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x70001930)
> at bss_dgram.c:1803
> > #2  0x77dc7830 in dtls1_accept (s=0x78c0) at
> d1_srvr.c:403
> > #3  0x004021ee in connection_handle(void*) ()
> > #4  0x003db4c07851 in start_thread () from /lib64/libpthread.so.0
> > #5  0x003db48e890d in clone () from /lib64/libc.so.6
> > (gdb)
> >
> >
> > I am also attaching the wireshark trace (port 4443) and a server key for
> decoding wireshark.
> >
> > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443
> >
> > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443
> -l 50 -n 5 16.181.38.161
> >
> > Thanks in advance for your valuable input
> I've CCed Irene, who did some testing recently on FreeBSD, where the
> implementation works.
> The server is waiting for a sender dry event which it should get.
>
> Which version of OpenSSL are you using and which OS are you using?
>
> Best regards
> Michael
> >
> > Regards,
> > Mahesh G S
> >
> >
> >
> > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen  franken.de> wrote:
> > > On 21 Feb 2017, at 09:53, mahesh gs  wrote:
> > >
> > > Hi,
> > >
> > > We have a client, server applications that is using SCTP as a
> transport protocol. We have to secure the connections using DTLS. I am
> using openssl version 1.0.2 which supports DTLS. But the problem i am
> facing is usage of DTLS SCTP related API's. Openssl documentation does not
> clearly explain all the SCTP related API's and usage sequence.
> > >
> > > I have tried going though internet and found most of the sites
> redirect to one link for SCTP DTLS sample code. But this 

Re: [openssl-users] Question RE certificate chain verification

[Walter H. via openssl-users]

On Tue, February 21, 2017 12:16, Jakob Curdes wrote:
> Hi, I am new to the list and have a question where it seems I cannot find
> the answer in archives here or in other sources.
>
> We want to verify the certificate chain of an "official" certificate, but
> including the revocation status of the intermediate certs, via CRL or
> OCSP.
> (The chain verification itself is easy and solved, our problems lie just
> with getting the revocation status of an arbitrary certificate).
>
> It seems to turn out that a) this is seldom done completely (otherwise I
> think there would be more "working recipes") and it is not easy to do it
> in a generic way as we keep getting various errors at different steps.
>
> Wtihout making it too long, we want to do the following:
> a) retrieve and save certificate from server via URL
> b)retrieve and save certificate chain from server
> c) determine OCSP URL or CRL list URL
> d1) verify cert against OCSP source OR
> d2) download CRL; then verify cert against CRL
>
> Up to c), everything is straightforward. We use openssl 1.0.1e-60.el7 from
> current CentOS 7.

try this:

CAFILE=/etc/pki/certs/ca-bundle.trust.crt

CERT=/tmp/cert.crt  <-- cert to validate
ISSUER=/tmp/issuer.crt   <-- issuing ca cert

OCSPURL=$(openssl x509 -in $CERT -noout -ocsp_uri)
OCSPHOST=$(echo "$OCSPURL" |gawk --field-separator=\/ '{ print $3 }' -)

OCSPRESULT=$(openssl ocsp -CAfile $CAFILE -no_nonce -noverify -issuer
$ISSUER -cert $CERT -url "$OCSPURL" -header Host $OCSPHOST |grep "$CERT")



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