Re: Server application hangs on SS_read, even when client disconnects
Hello Michael, Thanks for all those information. I corrected your suggested point (close parent process sockets). I also activated keepalive, with values adapted to my application. I hope this will solve my issue, but as the problem may take several weeks to occur, I will not know immediately if this was the origin :-) Many thanks for your help. Regards, Brice Le ven. 13 nov. 2020 à 18:52, Michael Wojcik a écrit : > > From: Brice André > > Sent: Friday, 13 November, 2020 09:13 > > > "Does the server parent process close its copy of the conversation > socket?" > > I checked in my code, but it seems that no. Is it needed? > > You'll want to do it, for a few reasons: > > - You'll be leaking descriptors in the server, and eventually it will hit > its limit. > - If the child process dies without cleanly closing its end of the > conversation, > the parent will still have an open descriptor for the socket, so the > network stack > won't terminate the TCP connection. > - A related problem: If the child just closes its socket without calling > shutdown, > no FIN will be sent to the client system (because the parent still has its > copy of > the socket open). The client system will have the connection in one of the > termination > states (FIN_WAIT, maybe? I don't have my references handy) until it times > out. > - A bug in the parent process might cause it to operate on the connected > socket, > causing unexpected traffic on the connection. > - All such sockets will be inherited by future child processes, and one of > them might > erroneously perform some operation on one of them. Obviously there could > also be a > security issue with this, depending on what your application does. > > Basically, when a descriptor is "handed off" to a child process by > forking, you > generally want to close it in the parent, unless it's used for parent-child > communication. (There are some cases where the parent wants to keep it > open for > some reason, but they're rare.) > > On a similar note, if you exec a different program in the child process (I > wasn't > sure from your description), it's a good idea for the parent to set the > FD_CLOEXEC > option (with fcntl) on its listening socket and any other descriptors that > shouldn't > be passed along to child processes. You could close these manually in the > child > process between the fork and exec, but FD_CLOEXEC is often easier to > maintain. > > For some applications, you might just dup2 the socket over descriptor 0 or > descriptor 3, depending on whether the child needs access to stdio, and > then close > everything higher. > > Closing descriptors not needed by the child process is a good idea even if > you > don't exec, since it can prevent various problems and vulnerabilities that > result > from certain classes of bugs. It's a defensive measure. > > The best source for this sort of recommendation, in my opinion, remains W. > Richard > Stevens' /Advanced Programming in the UNIX Environment/. The book is old, > and Linux > isn't UNIX, but I don't know of any better explanation of how and why to > do things > in a UNIX-like OS. > > And my favorite source of TCP/IP information is Stevens' /TCP/IP > Illustrated/. > > > May it explain my problem? > > In this case, I don't offhand see how it does, but I may be overlooking > something. > > > I suppose that, if for some reason, the communication with the client is > lost > > (crash of client, loss of network, etc.) and keepalive is not enabled, > this may > > fully explain my problem ? > > It would give you those symptoms, yes. > > > If yes, do you have an idea of why keepalive is not enabled? > > The Host Requirements RFC mandates that it be disabled by default. I think > the > primary reasoning for that was to avoid re-establishing virtual circuits > (e.g. > dial-up connections) for long-running connections that had long idle > periods. > > Linux may well have a kernel tunable or similar to enable TCP keepalive by > default, but it seems to be switched off on your system. You'd have to > consult > the documentation for your distribution, I think. > > By default (again per the Host Requirements RFC), it takes quite a long > time for > TCP keepalive to detect a broken connection. It doesn't start probing > until the > connection has been idle for 2 hours, and then you have to wait for the TCP > retransmit timer times the retransmit count to be exhausted - typically > over 10 > minutes. Again, some OSes let you change these defaults, and some let you > change > them on an individual connection. > > -- > Michael Wojcik > >
Re: Server application hangs on SS_read, even when client disconnects
Hello, And many thanks for the answer. "Does the server parent process close its copy of the conversation socket?" : I checked in my code, but it seems that no. Is it needed ? May it explain my problem ? " Do you have keepalives enabled?" To be honest, I did not know it was possible to not enable them. I checked with command "netstat -tnope" and it tells me that it is not enabled. I suppose that, if for some reason, the communication with the client is lost (crash of client, loss of network, etc.) and keepalive is not enabled, this may fully explain my problem ? If yes, do you have an idea of why keepalive is not enabled ? I thought that by default on linux it was ? Many thanks, Brice Le ven. 13 nov. 2020 à 15:43, Michael Wojcik a écrit : > > From: openssl-users On Behalf Of > Brice André > > Sent: Friday, 13 November, 2020 05:06 > > > ... it seems that in some rare execution cases, the server performs a > SSL_read, > > the client disconnects in the meantime, and the server never detects the > > disconnection and remains stuck in the SSL_read operation. > > ... > > > #0 0x7f836575d210 in __read_nocancel () from > /lib/x86_64-linux-gnu/libpthread.so.0 > > #1 0x7f8365c8ccec in ?? () from > /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 > > #2 0x7f8365c8772b in BIO_read () from > /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 > > So OpenSSL is in a blocking read of the socket descriptor. > > > tcp0 0 http://5.196.111.132:5413 > http://85.27.92.8:25856ESTABLISHED 19218/./MabeeServer > > tcp0 0 http://5.196.111.132:5412 > http://85.27.92.8:26305ESTABLISHED 19218/./MabeeServer > > > From this log, I can see that I have two established connections with > remote > > client machine on IP 109.133.193.70. Note that it's normal to have two > connexions > > because my client-server protocol relies on two distinct TCP connexions. > > So the client has not, in fact, disconnected. > > When a system closes one end of a TCP connection, the stack will send a > TCP packet > with either the FIN or the RST flag set. (Which one you get depends on > whether the > stack on the closing side was holding data for the conversation which the > application > hadn't read.) > > The sockets are still in ESTABLISHED state; therefore, no FIN or RST has > been > received by the local stack. > > There are various possibilities: > > - The client system has not in fact closed its end of the conversation. > Sometimes > this happens for reasons that aren't immediately apparent; for example, if > the > client forked and allowed the descriptor for the conversation socket to be > inherited > by the child, and the child still has it open. > > - The client system shut down suddenly (crashed) and so couldn't send the > FIN/RST. > > - There was a failure in network connectivity between the two systems, and > consequently > the FIN/RST couldn't be received by the local system. > > - The connection is in a state where the peer can't send the FIN/RST, for > example > because the local side's receive window is zero. That shouldn't be the > case, since > OpenSSL is (apparently) blocked in a receive on the connection. but as I > don't have > the complete picture I can't rule it out. > > > This let me think that the connexion on which the SSL_read is listening > is > > definitively dead (no more TCP keepalive) > > "definitely dead" doesn't have any meaning in TCP. That's not one of the > TCP states, > or part of the other TCP or IP metadata associated with the local port > (which is > what matters). > > Do you have keepalives enabled? > > > and that, for a reason I do not understand, the SSL_read keeps blocked > into it. > > The reason is simple: The connection is still established, but there's no > data to > receive. The question isn't why SSL_read is blocking; it's why you think > the > connection is gone, but the stack thinks otherwise. > > > Note that the normal behavior of my application is : client connects, > server > > daemon forks a new instance, > > Does the server parent process close its copy of the conversation socket? > > -- > Michael Wojcik >
Server application hangs on SS_read, even when client disconnects
Hello,
I have developed a client-server application with openssl and I have a
recurrent bug where, sometimes, server instance seems to be definitively
stuck in SSL_read call.
I have put more details of the problem here below, but it seems that in
some rare execution cases, the server performs a SSL_read, the client
disconnects in the meantime, and the server never detects the disconnection
and remains stuck in the SSL_read operation.
My server runs on a Debian 6.3, and my version of openssl is 1.1.0l.
Here is an extract of the code that manages the SSL connexion at server
side :
ctx = SSL_CTX_new(SSLv23_server_method());
BIO* bio = BIO_new_file("dhkey.pem", "r");
if (bio == NULL) ...
DH* ret = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
BIO_free(bio);
if (SSL_CTX_set_tmp_dh(ctx, ret) < 0) ...
SSL_CTX_set_default_passwd_cb_userdata(ctx, (void*)key);
if (SSL_CTX_use_PrivateKey_file(ctx, "server.key", SSL_FILETYPE_PEM) <=
0) ...
if (SSL_CTX_use_certificate_file(ctx, "server.crt", SSL_FILETYPE_PEM) <=
0) ...
if (SSL_CTX_check_private_key(ctx) == 0) ...
SSL_CTX_set_cipher_list(ctx, "ALL");
ssl_in = SSL_new(ctx);
BIO* sslclient_in = BIO_new_socket(in_sock, BIO_NOCLOSE);
SSL_set_bio(ssl_in, sslclient_in, sslclient_in);
int r_in = SSL_accept(ssl_in);
if (r_in != 1) ...
...
/* Place where program hangs : */
int read = SSL_read(ssl_in, &(((char*)ptr)[nb_read]), size-nb_read);
Here is the full stack-trace where the program hangs :
#0 0x7f836575d210 in __read_nocancel () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x7f8365c8ccec in ?? () from
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#2 0x7f8365c8772b in BIO_read () from
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#3 0x7f83659879a2 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#4 0x7f836598b70d in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#5 0x7f8365989113 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#6 0x7f836598eff6 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#7 0x7f8365998dc9 in SSL_read () from
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
#8 0x55b7b3e98289 in Socket::SslRead (this=0x7ffdc6131900, size=4,
ptr=0x7ffdc613066c)
at ../../Utilities/Database/Sync/server/Communication/Socket.cpp:80
Here is the result of "netstat -natp | grep " :
tcp 32 0 5.196.111.132:5412 109.133.193.70:51822
CLOSE_WAIT 19218/./MabeeServer
tcp 32 0 5.196.111.132:5412 109.133.193.70:51696
CLOSE_WAIT 19218/./MabeeServer
tcp 32 0 5.196.111.132:5412 109.133.193.70:51658
CLOSE_WAIT 19218/./MabeeServer
tcp0 0 5.196.111.132:5413 85.27.92.8:25856
ESTABLISHED 19218/./MabeeServer
tcp 32 0 5.196.111.132:5412 109.133.193.70:51818
CLOSE_WAIT 19218/./MabeeServer
tcp 32 0 5.196.111.132:5412 109.133.193.70:51740
CLOSE_WAIT 19218/./MabeeServer
tcp0 0 5.196.111.132:5412 85.27.92.8:26305
ESTABLISHED 19218/./MabeeServer
tcp6 0 0 ::1:36448 ::1:5432
ESTABLISHED 19218/./MabeeServer
>From this log, I can see that I have two established connections with
remote client machine on IP 109.133.193.70. Note that it's normal to have
two connexions because my client-server protocol relies on two distinct TCP
connexions.
>From this, I logged the result of a "tcpdump -i any -nn host 85.27.92.8"
during two days (and during those two days, my server instance remained
stuck in SSL_read...). On this log, I see no packet exchange on ports
85.27.92.8:25856 or 85.27.92.8:26305. I see some burst of packets exchanged
on other client TCP ports, but probably due to the client that performs
other requests to the server (and thus, the server that is forking new
instances with connections on other client ports).
This let me think that the connexion on which the SSL_read is listening is
definitively dead (no more TCP keepalive), and that, for a reason I do not
understand, the SSL_read keeps blocked into it.
Note that the normal behavior of my application is : client connects,
server daemon forks a new instance, communication remains a few seconds
with forked server instance, client disconnects and the forked process
finished.
Note also that normally, client performs a proper disconnection
(SSL_shutdown, etc.). But I cannot guarantee it never interrupts on a more
abrupt way (connection lost, client crash, etc.).
Any advice on what is going wrong ?
Many thanks,
Brice
Re: static linking libssl and libcrypto
Sorry, but you are wrong : using libSSL.a in your libApp.so library does not prevent you from using libSSL.so elsewhere in your program. In such case, your program would still need libSSL.so Le mer. 6 nov. 2019 à 09:38, Jakob Bohm via openssl-users < openssl-users@openssl.org> a écrit : > Regarding #1: Using libSSL.a instead of libSSL.so should avoid using > libSSL.so by definition. Otherwise something went seriously wrong > with the linking. Same for any other library. > > On 05/11/2019 18:22, Aijaz Baig wrote: > > Thank you for the information. > > > > I will address your points here: > > 1. I was not aware of the fact that only those symbols that have been > > used get imported when linking a library statically. So that very well > > could be the case. I didn't get what you mentioned about the static > > linking preventing the program from requiring libSSL.so. I mean the > > way I am linking my library should be of no concern to the source code > > right? Or so I think. > > > > 2. when I downloaded and compiled the openssl library (from source), I > > followed the INSTALL read me. All it resulted was libssl.a and > > libcrypto.a. I didn't find any file name libSSL.so. So how will this > > static library (archive) have references to libSSL.so on the system?? > > I am kind of confused here now. > > > > > > On Mon, Nov 4, 2019 at 4:59 PM Brice André > <mailto:br...@famille-andre.be>> wrote: > > > > Hello, > > > > It's not an open-ssl issue, but more a compiler specific one. > > > > With info you provided, I cannot tell you what you get as results, > > but two points that may help: > > > > 1. regarding the 87 ssl symbols : when you link with a library, > > only the useful symbols are imported. So, if the code in you > > libAPP library only uses some sparse functions of libSSL, it's > > normal you only have corresponding symbols in your final > > image. I don't know what you plan to do, but note that > > statically linking your dll with open-ssl will prevent this > > dll from needing the openssl dynamic library. But it will not > > prevent your main program to require the open-ssl library to > > run properly if some part of it is dynamically linked with > > open-ssl ! > > 2. depending on how you compiled your libssl.a, it can be either > > a static library containing the full openssl binary code, or a > > static library that just makes the "link" between you code and > > the ssl dynamic library. In the second case, even if you > > properly statically link with this lib, you will still need > > the dll to execute your program. > > > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 > >
Re: static linking libssl and libcrypto
Then it means you properly compiled SSL in static.
Regarding my first point, what I mean is that : if you statically link your
libApp.so with ssl library, it will no need any dynamic library
dependencies, which is probably what you want. But your libApp.so will be
loaded by a program. If this program also uses SSL (direct access, not
through your libApp.so library), and performs a dynamic link, you will
still need the ssl.so to run your application, even if your dll is
statically linked with it.
Regards,
Brice
Le mar. 5 nov. 2019 à 18:24, Aijaz Baig a écrit :
> ldd libAPP.so does NOT have any reference to libSSL.so or for that matter
> any SSL library. Which is why I had to use nm to check for SSL related
> symbols
>
> On Mon, Nov 4, 2019 at 6:31 PM Floodeenjr, Thomas <
> thomas_floodee...@mentor.com> wrote:
>
>> To check if you are linked statically or dynamically, what does ldd tell
>> you? (ldd libAPP.so) Your library should not have a dependency on
>> libssl.so or libcrypto.so if you are linked statically.
>>
>>
>>
>> -Tom
>>
>>
>>
>> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
>> Behalf Of *Aijaz Baig
>> *Sent:* Sunday, November 3, 2019 11:30 PM
>> *To:* openssl-users@openssl.org
>> *Subject:* static linking libssl and libcrypto
>>
>>
>>
>> I am trying to build a shared library that internally links openssl and
>> crypto libraries statically so I can use it in a production environment. To
>> that end I am using the following Makefile
>>
>> APPBASE=/home/AB/Documents/APP/APP_2.17.0
>>
>> OPENSSL1.0.2p_INSTALL_LOC=/home/AB/Documents/APP/OpenSSL-1.0.2p-installation
>>
>> CC=gcc
>>
>> CFLAGS= -Wall -g -O -fPIC
>>
>> RM= rm -f
>>
>> .PHONY: all clean
>>
>>
>>
>> src=$(wildcard *Generic/*.c *Linux/*.c)
>>
>> $(info source=$(src))
>>
>>
>>
>> #we use the custom compiled openssl version
>>
>> #and NOT the one available on the system
>>
>> #INC=-I/usr/include/openssl
>>
>> INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include/openssl
>>
>> INC+=$(foreach d,$(incdir),-I$d)
>>
>> $(info includes=$(INC))
>>
>>
>>
>> LIB=-L$(OPENSSL1.0.2p_INSTALL_LOC)/lib
>>
>> #LIB=-llibssl -llibcrypto
>>
>> LIB+=-lssl -lcrypto
>>
>> $(info links=$(LIB))
>>
>> #LIB+=-L/usr/lib/
>>
>>
>>
>> obj=$(src:.c=.o)
>>
>> all: libAPP.so
>>
>> clean:
>>
>> $(RM) *.o *.so
>>
>> $(shell find $(APPBASE) -type f -iname "*.o" -exec rm -rf {} \;)
>>
>>
>>
>> .c.o:
>>
>> ${CC} -static ${CFLAGS} $(INC) -c $< $(LIB) -o $@
>>
>>
>>
>> libAPP.so: $(obj)
>>
>> $(LINK.c) -shared $^ -o $@
>>
>> As mentioned here (
>> https://stackoverflow.com/questions/18185618/how-to-use-static-linking-with-openssl-in-c-c/25811538#25811538),
>> I've changed the linker flags to:
>>
>> -lcrypto -lz -ldl -static-libgcc
>>
>>
>>
>> but it doesn't seem to change the size of the generated so file. On
>> checking for references to SSL in this so file, I see there are a total of
>> 87 entries
>>
>>
>>
>> nm libAPP.so | grep -i "ssl" | wc -l
>>
>> 87
>>
>>
>>
>> whereas listing *only* the global symbols from libssl.a tells me it has
>> 1113 globally defined symbols.
>>
>> nm -g ../OpenSSL-1.0.2p-installation/lib/libssl.a | grep -i "ssl" | wc -l
>>
>> 1113
>>
>>
>>
>> I do not know if libSSL got indeed linked statically or not. Could
>> someone please shed some light on it?
>>
>>
>>
>> --
>>
>>
>> Best Regards,
>>
>> Aijaz Baig
>>
>
>
> --
>
> Best Regards,
> Aijaz Baig
>
Re: static linking libssl and libcrypto
Hello,
It's not an open-ssl issue, but more a compiler specific one.
With info you provided, I cannot tell you what you get as results, but two
points that may help:
1. regarding the 87 ssl symbols : when you link with a library, only the
useful symbols are imported. So, if the code in you libAPP library only
uses some sparse functions of libSSL, it's normal you only have
corresponding symbols in your final image. I don't know what you plan to
do, but note that statically linking your dll with open-ssl will prevent
this dll from needing the openssl dynamic library. But it will not prevent
your main program to require the open-ssl library to run properly if some
part of it is dynamically linked with open-ssl !
2. depending on how you compiled your libssl.a, it can be either a
static library containing the full openssl binary code, or a static library
that just makes the "link" between you code and the ssl dynamic library. In
the second case, even if you properly statically link with this lib, you
will still need the dll to execute your program.
Regards,
Brice
Le lun. 4 nov. 2019 à 07:28, Aijaz Baig a écrit :
> I am trying to build a shared library that internally links openssl and
> crypto libraries statically so I can use it in a production environment. To
> that end I am using the following Makefile
>
> APPBASE=/home/AB/Documents/APP/APP_2.17.0
> OPENSSL1.0.2p_INSTALL_LOC=/home/AB/Documents/APP/OpenSSL-1.0.2p-installation
> CC=gcc
> CFLAGS= -Wall -g -O -fPIC
> RM= rm -f
> .PHONY: all clean
>
> src=$(wildcard *Generic/*.c *Linux/*.c)
> $(info source=$(src))
>
> #we use the custom compiled openssl version
> #and NOT the one available on the system
> #INC=-I/usr/include/openssl
> INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include/openssl
> INC+=$(foreach d,$(incdir),-I$d)
> $(info includes=$(INC))
>
> LIB=-L$(OPENSSL1.0.2p_INSTALL_LOC)/lib
> #LIB=-llibssl -llibcrypto
> LIB+=-lssl -lcrypto
> $(info links=$(LIB))
> #LIB+=-L/usr/lib/
>
> obj=$(src:.c=.o)
> all: libAPP.so
> clean:
> $(RM) *.o *.so
> $(shell find $(APPBASE) -type f -iname "*.o" -exec rm -rf {} \;)
>
> .c.o:
> ${CC} -static ${CFLAGS} $(INC) -c $< $(LIB) -o $@
>
> libAPP.so: $(obj)
> $(LINK.c) -shared $^ -o $@
>
> As mentioned here (
> https://stackoverflow.com/questions/18185618/how-to-use-static-linking-with-openssl-in-c-c/25811538#25811538),
> I've changed the linker flags to:
> -lcrypto -lz -ldl -static-libgcc
>
> but it doesn't seem to change the size of the generated so file. On
> checking for references to SSL in this so file, I see there are a total of
> 87 entries
>
> nm libAPP.so | grep -i "ssl" | wc -l
> 87
>
> whereas listing *only* the global symbols from libssl.a tells me it has
> 1113 globally defined symbols.
> nm -g ../OpenSSL-1.0.2p-installation/lib/libssl.a | grep -i "ssl" | wc -l
> 1113
>
> I do not know if libSSL got indeed linked statically or not. Could someone
> please shed some light on it?
>
> --
>
> Best Regards,
> Aijaz Baig
>
Re: [openssl-users] Problem with certificate check when it does not match CN
Dear Viktor, Thanks for your answer. I Know that the current certificate is the old one, but this is because my service is in production. I tested new certificate this evening to limit the number of impacted clients. And as it did not worked, i reinstalled previous certificate waiting a solution for the new one. If it may help, i can installe new cerrificate on a test site. Regards, Brice Le dim. 18 déc. 2016 à 22:26, Viktor Dukhovni <openssl-us...@dukhovni.org> a écrit : > > > > On Dec 18, 2016, at 3:05 PM, Brice André <br...@famille-andre.be> wrote: > > > > > > I developped the service a few years ago and got wildcard certificates > from Startcom. Due to the recent probems with startcom, I migrated my > certificates to COMODO. I also tried to rationalise the number of > certificates, and I think several of my problems come from here. > > > > Your problem is an incomplete migration. The certificate > > presented by www.online-rdv.be on port 443 is the StartCom > > certificate you intended to replace. > > > > > For a dedicate web service, I use a server located at > https://www.online-rdv.be/v1/ With my previous certificate, CN of > certificate was a wildcard certificate : *.online-rdv.be. Everything > worked fine. > > > > See below for the presented chain: > > > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 2304556835693556 (0x82ffb738e63f4) > > Signature Algorithm: sha256WithRSAEncryption > > Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate > Signing, CN=StartCom Class 2 Primary Intermediate Server CA > > Validity > > Not Before: Oct 14 10:40:52 2015 GMT > > Not After : Oct 14 15:54:25 2017 GMT > > Subject: C=BE, ST=Hainaut, L=Couillet, O=Brice Andr\xE9, CN=*. > online-rdv.be/emailAddress=hostmas...@online-rdv.be > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:c7:15:56:aa:b7:13:50:b6:30:af:aa:53:00:d1: > > 34:ae:d7:c9:62:95:80:f7:70:93:d1:13:16:04:bd: > > 70:ac:fa:b0:74:0d:ce:c2:1c:e6:96:d0:cd:5d:4d: > > 59:e7:bb:1d:34:7e:05:b3:60:96:aa:fa:88:4d:75: > > 61:52:59:f5:ae:58:86:7d:7a:5d:93:c1:f8:dc:be: > > 86:25:c1:d4:63:60:eb:1d:ab:8a:da:a4:4d:4a:17: > > 40:ef:02:55:57:2b:53:42:0e:ac:21:7c:13:6c:c4: > > ed:72:ba:99:8a:63:b3:02:c9:3f:ff:36:d6:a2:81: > > 95:38:32:ec:ae:c7:fe:75:54:17:82:b5:16:c9:ae: > > c5:46:05:28:b5:c3:24:76:65:60:dd:21:15:c7:28: > > b8:ec:a5:d2:15:bf:5d:58:e3:cb:ef:ca:9a:09:54: > > 31:f1:4d:b7:ae:89:dd:60:a7:8f:1c:d7:06:8d:91: > > ab:9f:68:36:fa:e9:ba:9c:ff:64:c1:58:9b:d7:de: > > df:b9:ac:bd:e0:05:08:d1:fb:a1:02:08:01:11:bf: > > fc:9c:73:7b:b7:7d:ec:0f:0c:bf:73:8b:fc:6e:b1: > > 56:dd:ca:58:00:d8:80:53:8e:f0:ff:72:70:ae:14: > > ad:0c:0e:ae:23:9c:1a:a2:dd:11:41:6e:8d:87:f5: > > 6a:35 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Basic Constraints: > > CA:FALSE > > X509v3 Key Usage: > > Digital Signature, Key Encipherment, Key Agreement > > X509v3 Extended Key Usage: > > TLS Web Client Authentication, TLS Web Server > Authentication > > X509v3 Subject Key Identifier: > > E5:7E:1E:3D:4C:C1:71:36:3A:FE:F8:D3:E7:E2:5F:A1:7D:8B:42:A3 > > X509v3 Authority Key Identifier: > > > keyid:11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86 > > > > X509v3 Subject Alternative Name: > > DNS:*.online-rdv.be, DNS:online-rdv.be, DNS:online-rdv.biz, > DNS:*.online-rdv.biz, DNS:online-rdv.com, DNS:*.online-rdv.com, DNS: > online-rdv.eu, DNS:*.online-rdv.eu, DNS:online-rdv.info, DNS:*. > online-rdv.info, DNS:online-rdv.net, DNS:*.online-rdv.net, DNS: > online-rdv.org, DNS:*.online-rdv.org, DNS:rdv-doc.be, DNS:*.rdv-doc.be, > DNS:doc-rdv.be, DNS:*.doc-rdv.be > > X509v3 Certificate Policies: > > Policy: 2.23.140.1.2.2 > > Policy: 1.3.6.1.4.1.23223.1.2.3 > > CPS: http://www.startssl.com/policy.pdf > >
[openssl-users] Problem with certificate check when it does not match CN
Dear all, I use a gsoap application for which I write the server (php/apache) and client (gsoap and openssl). As I am pretty sure my problem comes from openssl and not gsoap, I am asking my question here. I developped the service a few years ago and got wildcard certificates from Startcom. Due to the recent probems with startcom, I migrated my certificates to COMODO. I also tried to rationalise the number of certificates, and I think several of my problems come from here. For a dedicate web service, I use a server located at https://www.online-rdv.be/v1/ With my previous certificate, CN of certificate was a wildcard certificate : *.online-rdv.be. Everything worked fine. But now, my new certificate is common for all my web sites. So, the CN is www.ams-solutions.be and, in the list of alternate names, I have an entry *. online-rdv.be. >From this point, all gsoap connections fail from SSL checks. If checked the certificate bundle provided to my gsoap client application and it contains root certificate, as well as intermediate certificates. This same soap server is directly used by the website and all browsers I checked do not encounter the problem. So, my best guess is that the way I configure openssl with gsoap is not correct and does not allow validating a web site if it does not match the CN certificate field. I do no special configuration (nearly all default parameters). In fact, the only ssl configuration I perform is the following : soap_ssl_init(); soap_ssl_client_context(service.soap, SOAP_SSL_DEFAULT, NULL, NULL, cert_path.GetCString(), NULL, NULL); where cert_path points to a file with root and intermediate certificates. Any suggestion on how to solve my problem ? Regards, Brice -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
How to use OpenSSL with existing multi-thread client code ?
Hello, I have a multi-thread application that does not use SSL connexion. I would want to use open-ssl to protect the communication, but as the original code is multi-thread, I run into some troubles... Basically, the client sends several (hundreds of) commands, and for each command, the server answers with a response. Currently, one client thread is used for sending commands, and a second thread is used for handling answer, each one with blocking calls to socket. My understanding of the OpenSSL documentation is that I am no more allowed to do so. A simple solution would consist into changing the client code so that it waits the answer of each command before processing next one, but this would highly reduce the speed of my application so, I would want to avoid this. Another solution would be to emulate a multi-thread application whilst guaranteing no concurrent access to open-ssl stuff by using non-blocking bio (as well as other mechanisms like semaphores, select statements, etc.). I think I have an efficient solution for this, but in this case, I need to be allowed to do a SSL_write after a SSL_read failed returning SSL_ERROR_WANT_READ (and vice-cersa). My problem is that, when reading the doc, it is unclear if this is allowed... The doc says that, in this case, next call to SSL_read shall be done with same arguments, but it does not say if we can perform a SSL_write before... Another solution would consist in buffering commands on the client side, and responses on the server side for an efficient communication in mono-thread application. But this would require changes to the server side and in the logicl of client/server communication and I would want to avoid that. So, my questions are : - Am I allowed to perform an SSL_write after a SSL_read failed ? And, if yes, are there limitations (for example, if the SSL_read sends a SSL_ERROR_WANT_WRITE, am I still allowed to perform a SSL_write ?) - Is there a simpler solution to my problem ? Thanks in advance, Brice __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_VERIFY_PEER and self-signed certificates
Dear Dave, Thanks for your help. I solved my problem and I am very ashamed... I tried with the ssl client command line of my freshly compiled openssl version and got the same error. After investigation, I realised that the official windows binary client failed too. Thus, I was wondering why it worked a few days before and realised that, when I performed this test first, I downloaded my server certificate directly from my server, whilst when testing it today, I took the certificate used by my C++ client application. After a small check, I realised that this C++ client certificate was corrupted. So, I think that my first problem was the initialisation of the cert store, but you helped me solving it a few days before. But, in the mean time, when investigating my problem, I probably did a mistake that corrupted the copy of my certificate located on the client side (client and server are not on the same computer). As the error was the same, and as this error let me think that the problem was linked to the fact that the certificate was self-signed, I did not realise this stupid thing. Sorry to have bothered you with such stupid problem. Regards, Brice 2013/6/1 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Friday, 31 May, 2013 06:00 snip The problem seems indeed to be located in the call to X509_STORE_CTX_get1_issuer. In this function, the function X509_STORE_get_by_subject returns an error. When digging into this code, the following loop is executed once : for (i=vs-current_method; isk_X509_LOOKUP_num(ctx-get_cert_methods); i++) [and does nothing because by_file method handler is null] You've already gone too far. See next. From that point, I am a little stuck... I do not see any error in the SSL_CTX_load_verify_locations function call that would explain why my store is initialised with a handler that does not support get_by_subject method, and I do not find any reason why the call to X509_STORE_CTX_get1_issuer chooses this method instead of another. So, I really find no may to avoid this problem. by_file and by_dir work differently: If you call SSL_CTX_load_verify_locations thence X509_STORE_load_locations with CAfile, it puts the by_file lookup method in the store and also reads the file, converting all the certs and CRLs to in-memory structures in store.objs which is a STACK_OF(X509_OBJECT) under your SSL_CTX. When the handshake occurs and X509_verify_cert via _get1_issuer calls X509_STORE_get_by_subject using that store, the second statement is tmp=X509_OBJECT_retrieve_by_subject(ctx-objs,...) which is hard to debug at least on my machine because it is inlined but should find the loaded cert in .objs, so a few lines later if(tmp==NULL...) skips over the loop you looked at and found to be ineffective. If you use CApath, _load_locations just puts the by_dir lookup method in the store. At verify time, X509_STORE_get_by_subject finds nothing in store.objs, so the loop does call the by_dir get_cert_by_subject routine which looks in the specified dir(s) for a suitable file. I have the feeling that, if I use the CApath field instead of the CAFile field of function SSL_CTX_load_verify_locations, this could solve my problem, as the by_dir.c supports the get_by_subject but : - I have no idea on how to initialise a directory with proper files (in production, I will have a PEM file containing more than one certificate) - I suppose there should be a way to use openssl like I am doing now... If you do want to use CApath by_dir, choose or create a directory, put each cert or CRL you want in a separate PEM file there and either: - name each file subjecthash.n for a cert where subjecthash is calculated by x509 -subject_hash and n is the 0 for the first or only cert with that hash and 1,2... etc for any duplicates, or issuerhash.rn for a CRL with crl -hash and 0,1,2... similarly. - name each file anything you like such as FredServer.cer and create a symlink to it using the hashname as above - Windows doesn't have symlinks that people can use (although NTFS does internally) so you must use the first method - Unix does have symlinks and if you want the second method there is a script c_rehash which goes through and computes and creates the hashnamed links for you. - the manpage for SSL_CTX_load_verify_locations has some of this Any help would be higly appreciated, as I am currently completely stuck... Thanks in advance, Brice 2013/5/31 Dave Thompson dthomp...@prinpay.com: - use a (re)build with symbols and step through it using a good debugger (preferably gdb); in particular, after _load_verify ctx-cert_store-objs-stack should have num=1 (and data should point to a pointer that's actually to an X509_OBJECT that contains a pointer to the desired cert, but that's harder to look at), and the first time you get to X509_STORE_CTX_get1_issuer from X509_verify_cert
Re: SSL_VERIFY_PEER and self-signed certificates
Hello Dave,
Thanks for this info.
I compiled my own openssl lib with debug support and started debugging.
The problem seems indeed to be located in the call to
X509_STORE_CTX_get1_issuer. In this function, the function
X509_STORE_get_by_subject returns an error. When digging into this
code, the following loop is executed once :
for (i=vs-current_method; isk_X509_LOOKUP_num(ctx-get_cert_methods); i++)
In the only iteration it performs, the function
sk_X509_LOOKUP_value(ctx-get_cert_methods,i) returns a struct
initialised with by_file.c X509 handler, which looks like this :
X509_LOOKUP_METHOD x509_file_lookup=
{
Load file into cache,
NULL,/* new */
NULL,/* free */
NULL, /* init */
NULL,/* shutdown */
by_file_ctrl,/* ctrl */
NULL,/* get_by_subject */
NULL,/* get_by_issuer_serial */
NULL,/* get_by_fingerprint */
NULL,/* get_by_alias */
};
Thus, the call to X509_LOOKUP_by_subject fails as the provided handler
does not support this method.
From that point, I am a little stuck... I do not see any error in the
SSL_CTX_load_verify_locations function call that would explain why
my store is initialised with a handler that does not support
get_by_subject method, and I do not find any reason why the call to
X509_STORE_CTX_get1_issuer chooses this method instead of another. So,
I really find no may to avoid this problem.
I have the feeling that, if I use the CApath field instead of the
CAFile field of function SSL_CTX_load_verify_locations, this could
solve my problem, as the by_dir.c supports the get_by_subject but :
- I have no idea on how to initialise a directory with proper files
(in production, I will have a PEM file containing more than one
certificate)
- I suppose there should be a way to use openssl like I am doing now...
Any help would be higly appreciated, as I am currently completely stuck...
Thanks in advance,
Brice
2013/5/31 Dave Thompson dthomp...@prinpay.com:
From: owner-openssl-us...@openssl.org On Behalf Of Brice André
Sent: Thursday, 30 May, 2013 04:08
I tested [s_client] and it seems to work properly, which, I
suppose, means that the problem resides in my client code. I
copy-pasted the output below.
I think so; see more below.
I just find something strange on the server : to write my server code,
I followed a tuto where they initialised a diffie-helman key in the
server side. I was not sure of the utility of that and thus, I
performed several tests with the command you provided : with and
without this initialisation on the server side. In both cases, this
works properly. So, I am a little bit confused about that. I would
want to remove that part, but I am not sure if it may be useful...
I presume you mean *temporary* Diffie-Hellman *parameters* i.e.
SSL_CTX_set_tmp_dh (or _callback). The actual key using those
parameters is generated inside openssl. This is for ciphersuites
using ephemeral or anonymous DH key-exchange, abbreviated
EDH or DHE (better to avoid confusing EDH with ECDH which is
different) and ADH. SSL/TLS also defines ciphersuites using
static Diffie-Hellman, but openssl does not implement them;
plus you can't have a selfsigned cert for a (static) DH key.
Your key is RSA so s_client by default and your client as posted
supports both ciphersuites with DHE (DHE-RSA) and without (RSA, or
akRSA to avoid ambiguity). Other kinds of key/cert would differ.
I believe (but didn't check) that both will prefer DHE-RSA; thus
you might observe the difference if either endpoint displays
SSL_get_cipher_name(ssl) or equivalent after handshake, or
when you use s_client which displays this among other things.
The advantage of DHE-RSA over akRSA is perfect forward secrecy:
assuming the endpoints (together) put sufficient entropy into
their DHE keys, the session keys cannot be recovered and thus
logged session data cannot be decrypted even if the (server's)
privatekey is later compromised. Google for more. In a situation
where you're doing both endpoints (no interop) and trust your
own key management, PFS probably doesn't have any benefit.
I joined my client code. The interesting function is
wxSSLSocketClient::InitiateSSLSession. This code uses the wxWidgets
library and thus, it uses the wxSocketClient (wxWidgets socket
implementation) with a dedicated BIO so that openssl can handle it.
This code is extracted from the wxEMail project (I am the maintaniner
of this project). But, in this project, I did not implement the server
certificate check stuff. Thus, this version is slighlty modified to
perform those additional checks.
You will easily identify which part is original code and which one is
not because original code was designed to work in static link as well
as dynamic link (with a manual load of library). So, in original code,
all ssl calls are encapsulated in a macro. The modified version
currenlty only support
Re: SSL_VERIFY_PEER and self-signed certificates
.)E.G;./`.4.Bt.H
0070 - d7 82 71 66 d5 5c 1d fb-84 86 10 93 d9 59 d1 cd ..qf.\...Y..
0080 - 72 ac be d8 bc af 23 a1-00 90 a7 4b 68 ef 58 69 r.#Kh.Xi
0090 - f5 e7 75 b0 be 33 d4 19-d8 e0 81 b4 b8 37 bc 79 ..u..3...7.y
Start Time: 1369897977
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
2013/5/29 Dave Thompson dthomp...@prinpay.com:
From: owner-openssl-us...@openssl.org On Behalf Of Brice André
Sent: Wednesday, 29 May, 2013 03:14
I performed a test yesterday with the instruction
SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM);
replaced by
SSL_CTX_load_verify_locations(ctx, path_to_file, NULL);
Where path_to_file points to my file server.crt. The function
returns 1 so, I expect my certificate to be properly initialised.
To be exact, the client's trustore containing your cert.
One possible problem here: _load_verify_ accepts a sequence of
(PEM) certs, including zero, skipping any invalid format(s).
Make sure the client's file is/contains an exact copy of the
server's certfile, at least the lines from dash-BEGIN to dash-END,
including eol (either NL or CRLF okay) after each line (including
the dash-END line) and body lines not longer than 76 characters.
If you copied the content by cut-and-paste or sending in an email
or something like that, these sometimes go wrong. If you transferred
the file using FTP or SCP or similar, they shouldn't. (FTP mode A
may convert but not add/delete/move eols, and that is okay.)
But, whn I perform the connect, I get an error. The corresponding
error message is :
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
After the connect failed, the function SSL_get_peer_certificate(ssl)
returns NULL and the function SSL_get_verify_result(ssl) returns 18
(X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same
problem as before.
It should work and does for me, as long as the client CAfile is
exactly the (selfsigned) cert the server is using; and you don't have
KeyUsage excluding certSign, but that gives a different error.
If it isn't damaged per above and you have commandline on the client try
openssl s_client -connect host:port -CAfile same.server.crt.file
and see what it says for Verify return code at the end of SSL-session
(note s_client unlike a real app will proceed even if verify error).
My server is also printing an error message:
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
That's consistent; if the client decides the server cert is bad,
the client aborts the handshake with an alert like that.
(The exact alert may vary SSL vs TLS, but always some alert.)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
// Name:wxSSLSocketClient.cpp
// Purpose: This class implements the wxSSLSocketClient
// Author: Brice Andr�
// Created: 2011/01/25
// RCS-ID: $Id: mycomp.cpp 505 2007-03-31 10:31:46Z frm $
// Copyright: (c) 2011 Brice Andr�
// Licence: wxWidgets licence
/
#ifdef OPEN_SSL_STATIC_LINK
#define CALL_SSL(lib,func) func
#else
#define CALL_SSL(lib,func) lib.func
#endif
// For compilers that support precompilation, includes wx.h.
#include wx/wxprec.h
#ifdef __BORLANDC__
#pragma hdrstop
#endif
// includes
#ifndef WX_PRECOMP
// here goes the #include wx/abc.h directives for those
// files which are not included by wxprec.h
#endif
#include wx/ssl/wxSSLSocketClient.h
wxSSLSocketClient::OpenSslInitialisator::OpenSslInitialisator()
{
/* We perform a lazy load of lib so that it does not fail if openssl lib could not be loaded in case it is not requested */
lib_is_initialised = false;
}
wxSSLSocketClient::OpenSslInitialisator::~OpenSslInitialisator()
{
}
const wxSSLSocketClient::OpenSslInitialisator::LibIf_t wxSSLSocketClient::OpenSslInitialisator::GetLibIf()
{
/* Check if lib was already loaded */
if (!lib_is_initialised)
{
#ifndef OPEN_SSL_STATIC_LINK
/* load the library */
if (!ssl_lib.Load(wxT(ssleay32)))
{
throw Exception(wxT(Unable to load ssleay32 dynamic library));
}
if (!lib_eay.Load(wxT(libeay32)))
{
throw Exception(wxT(Unable to load libeay32 dynamic library));
}
/* Initialise the library */
((void(*)(void))LoadSymbol(ssl_lib, wxT(SSL_load_error_strings), wxT(ssleay32)))();
((void(*)(void))LoadSymbol(ssl_lib, wxT(SSL_library_init), wxT(ssleay32)))();
/* Initialise all requested symbols */
lib_if.SSLv23_client_method = (const SSL_METHOD*(*)(void))LoadSymbol
Re: SSL_VERIFY_PEER and self-signed certificates
Hello Dave, Once again, thanks for your help. I performed a test yesterday with the instruction SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM); replaced by SSL_CTX_load_verify_locations(ctx, path_to_file, NULL); Where path_to_file points to my file server.crt. The function returns 1 so, I expect my certificate to be properly initialised. But, whn I perform the connect, I get an error. The corresponding error message is : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed After the connect failed, the function SSL_get_peer_certificate(ssl) returns NULL and the function SSL_get_verify_result(ssl) returns 18 (X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same problem as before. My server is also printing an error message: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Regards, Brice 2013/5/28 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Monday, 27 May, 2013 23:45 You are right, I am using a self-signed certificate for use by my server. In fact, I do not perform client authentication in my application : only the server shall be authentified by ssl. The client is authentified by another mechanism. Here are how I generate my RSA key and my certificate: openssl genrsa -des -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt Asides: you could combine those: req -new -newkey rsa:2048 replaces genrsa req -new -x509 replaces x509 -signkey but the way you have it works. Also, 54+ years is a pretty long period! The only file that I transmit to my client is server.crt. Good. I think that all those files are OK because, on the server side, once everything is initialised, the command SSL_CTX_check_private_key is happy with it. In order to initialise the truststore of my client, I copy the server.crt file somewhere, and I execute the following command : SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM); Bad. That attempts to use the cert as the *client's* cert, which has no effect because you didn't give the client the privatekey, and rightly (the client shouldn't have the server's privatekey, and you say you don't want ssl-level client-auth anyway). Do I have to generate another file ? Or do I have to perform another configuration in my client ? There are two standard ways to set up a truststore for openssl lib, in your case the client's truststore to trust the server. SSL_CTX_load_verify_locations (ctx, fileornull, pathornull) tells openssl to use the (selfsigned root and/or EE) certs concatenated in one PEM file named by fileornull if not null, and/or stored in individual PEM files using the subjecthash for link or name in directory pathornull if not null. SSL_CTX_set_default_verify_paths (ctx) does something similar but using environment-variable settings or compiled default values for the file and/or path, usually systemwide places (for all apps on the system) something like /etc/openssl/cert.pem and /etc/openssl/certdir . Most of the commandline utilities allow you to specify -CAfile and/or -CApath for the first way, or default to the second way. Since you have one cert in one PEM file, the fileornull (CAfile) approach is simplest. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_VERIFY_PEER and self-signed certificates
Hello Jakob, All commands described in my mail are executed from the client. I only try to perform server authentication by certificate, and my problem is that the client is not able to perform this authentication. I think that my server code is ok (but I may be wrong). On the server side, the private key and certificate are initialised as follows: SSL_CTX_use_PrivateKey_file(ctx, server.key, SSL_FILETYPE_PEM) SSL_CTX_use_certificate_file(ctx, server.crt, SSL_FILETYPE_PEM) All commands return proper exit code and I added the following call to check if everything is properly initialised : SSL_CTX_check_private_key(ctx) And it also returns proper exit code. Regards, Brice 2013/5/29 Jakob Bohm jb-open...@wisemo.com: Hello, Just a little hint: Your questions would be much clear if you state, at each step, which end of the connection each thing applies to, like at what end did you call SSL_CTX_load_verify_locations, at what end did you get which error messages etc. I suspect this may be the cause of some confusion here. On 5/29/2013 9:14 AM, Brice André wrote: Hello Dave, Once again, thanks for your help. I performed a test yesterday with the instruction SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM); replaced by SSL_CTX_load_verify_locations(ctx, path_to_file, NULL); Where path_to_file points to my file server.crt. The function returns 1 so, I expect my certificate to be properly initialised. But, whn I perform the connect, I get an error. The corresponding error message is : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed After the connect failed, the function SSL_get_peer_certificate(ssl) returns NULL and the function SSL_get_verify_result(ssl) returns 18 (X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same problem as before. My server is also printing an error message: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Regards, Brice 2013/5/28 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Monday, 27 May, 2013 23:45 You are right, I am using a self-signed certificate for use by my server. In fact, I do not perform client authentication in my application : only the server shall be authentified by ssl. The client is authentified by another mechanism. Here are how I generate my RSA key and my certificate: openssl genrsa -des -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt Asides: you could combine those: req -new -newkey rsa:2048 replaces genrsa req -new -x509 replaces x509 -signkey but the way you have it works. Also, 54+ years is a pretty long period! The only file that I transmit to my client is server.crt. Good. I think that all those files are OK because, on the server side, once everything is initialised, the command SSL_CTX_check_private_key is happy with it. In order to initialise the truststore of my client, I copy the server.crt file somewhere, and I execute the following command : SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM); Bad. That attempts to use the cert as the *client's* cert, which has no effect because you didn't give the client the privatekey, and rightly (the client shouldn't have the server's privatekey, and you say you don't want ssl-level client-auth anyway). Do I have to generate another file ? Or do I have to perform another configuration in my client ? There are two standard ways to set up a truststore for openssl lib, in your case the client's truststore to trust the server. SSL_CTX_load_verify_locations (ctx, fileornull, pathornull) tells openssl to use the (selfsigned root and/or EE) certs concatenated in one PEM file named by fileornull if not null, and/or stored in individual PEM files using the subjecthash for link or name in directory pathornull if not null. SSL_CTX_set_default_verify_paths (ctx) does something similar but using environment-variable settings or compiled default values for the file and/or path, usually systemwide places (for all apps on the system) something like /etc/openssl/cert.pem and /etc/openssl/certdir . Most of the commandline utilities allow you to specify -CAfile and/or -CApath for the first way, or default to the second way. Since you have one cert in one PEM file, the fileornull (CAfile) approach is simplest. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, 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 Project http://www.openssl.org User Support Mailing List
SSL_VERIFY_PEER and self-signed certificates
Hello everyone, I am writing a client-server application in C++ with open-ssl to secure the connection. At this stage I successfully implemented all communication between my server and client with ssl encryption, but I am still missing a feature : checking the certificate of my server. As I am using this for securing a connection between my server and my client application installed on different machines, I do not plan to get a certificate from verisign or another ssl authority : I plan to generate my self-signed certificate and to embed it in my client. Now, my problem is that, when I configure openssl to check the peer certificate, with the SSL_set_verify command and the SSL_VERIFY_PEER option, I get the error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT when handshaking the connection on the client side. My understanding of this error is that, by default, open-ssl is not accepting self-signed certificates. So, my question is how can I configure open-ssl to accept self-signed certificates ? Thanks in advance, Brice __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_VERIFY_PEER and self-signed certificates
Hello Dave, Thank you for your answer. You are right, I am using a self-signed certificate for use by my server. In fact, I do not perform client authentication in my application : only the server shall be authentified by ssl. The client is authentified by another mechanism. Here are how I generate my RSA key and my certificate: openssl genrsa -des -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt The only file that I transmit to my client is server.crt. I think that all those files are OK because, on the server side, once everything is initialised, the command SSL_CTX_check_private_key is happy with it. In order to initialise the truststore of my client, I copy the server.crt file somewhere, and I execute the following command : SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM); Do I have to generate another file ? Or do I have to perform another configuration in my client ? Regards, Brice 2013/5/28 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Monday, 27 May, 2013 14:48 I am writing a client-server application snip I plan to generate my self-signed certificate and to embed it in my client. To be clear, a self-signed cert for (used by) the server. A self-signed cert for the client would be different, but client-auth is rarely used and I expect you would have said so. Now, my problem is that, when I configure openssl to check the peer certificate, with the SSL_set_verify command and the SSL_VERIFY_PEER option, I get the error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT when handshaking the connection on the client side. My understanding of this error is that, by default, open-ssl is not accepting self-signed certificates. Are you setting up the client truststore, and how? By default openssl doesn't trust *any* peer cert, self-signed or not. If you are setting up truststore, you aren't doing it right. So, my question is how can I configure open-ssl to accept self-signed certificates ? Put a self-signed entity cert, like a CA root (also self-signed), in the (client's) truststore using _default_verify_paths, _load_verify_locations, or by hand, as applicable. One gotcha specific to self-signed EE certs at least in openssl: if the KeyUsage extension is present it must include CertSign (in addition to digSign and maybe keyEnc needed in a CA-issued EE cert). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_UNDEFINED_FUNCTION error with self-made BIO
Hello everyone,
I am new to openssl and I am currently trying to write a small wrapper for
this library that will allow it to be used with wxWidgets. wxWidgets is a
cross-platform GUI library that offers network facilities. My goal is to
enrich the wxSocketClient implementation with ssl capabilities.
So, in order to use the existing wxSocketClient for I/O operations, I
decided to write my own BIO. I then implemented a function
wxSSLSocketClient::InitiateSSLSession that is supposed to negociate a SSL
connection, as well as a wxSSLSocketClient::TerminateSSLSession function
that is supposed to terminate this SSL connection.
My problem arises when trying to establish the SSL connection. I execute
the following code :
/* Configure ssl context */
ctx = ssl_lib.SSL_CTX_new(ssl_lib.SSLv23_client_method());
//ssl_lib.SSL_CTX_ctrl(ctx,SSL_CTRL_OPTIONS,SSL_OP_ALL,NULL);
/* Create SSL connection */
ssl = ssl_lib.SSL_new(ctx);
if (ssl != NULL)
{
/* Configure cypher algorithms supported */
ssl_lib.SSL_set_cipher_list(ssl, ALL);
bio = ssl_lib.BIO_new(SslBio::GetBio());
bio-ptr = this;
ssl_lib.SSL_set_bio(ssl,bio,bio);
ssl_lib.SSL_set_connect_state(ssl);
int ret = ssl_lib.SSL_connect(ssl);
if (ret = 0)
{
... error
}
...
The problem arises when invoking the SSL_connect. When invoking this
command, the write command of my BIO is invoked and, after, the SSL_connect
function returns with code -1. A call to SSL_get_error returns the error 1,
and by invoking the 'ERR_get_error' and 'ERR_error_string', I can retrieve
the following text error message :
Error 336351298 : error:140C5042:SSL
routines:SSL_UNDEFINED_FUNCTION:called a function you should not call
I am not sure my BIO implementation is related to this problem, but in
case of, here is the code of the relevant functions called before the crash
:
BIO_METHOD* wxSSLSocketClient::SslBio::GetBio()
{
static BIO_METHOD methods =
{
BIO_TYPE_SOCKET,
wxEmail Socket,
Write,
Read,
Puts,
Gets,
Ctrl,
Create,
Destroy,
NULL,
};
return methods;
}
...
int wxSSLSocketClient::SslBio::Write(BIO* bio, const char* buffer, int
nbytes)
{
wxLogDebug(Will write...);
wxSSLSocketClient* ptr = (wxSSLSocketClient*)bio-ptr;
ptr-Write(buffer, nbytes);
if (ptr-Error())
{
return -1;
}
else
{
return ptr-LastCount();
}
}
...
int wxSSLSocketClient::SslBio::Create(BIO* bio)
{
bio-init=1;
bio-num=-1;
bio-ptr=NULL;
bio-flags=0;
return 1;
}
One last information that can maybe be useful : I am using the bio-ptr
field to store internal stuff necessary for my implementation. So, this
field is overriden after BIO initialisation.
Any help would be highly appreciated.
Thanks in advance,
Brice André
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
