suddenly problem with certificates / error in SSLv3 read client certificate B
Hello! I have a huge problem with freeradius 2.2.0 on my eisfair server (www.eisfair.org) and users using certificates to authenticate. first of all: this should not be a "how must I config my freeradius to work?" problem. These installation with these certificates and these config worked for over 8 month very well. And suddenly I got the problem. Every client with user/pass works still fine. The problem is about the users with certificates (windows xp and android). the certificates are not outdated: list of active certificates: V 13-01-28 13:16:17 Z 01 unknown /C=DE/ST=Somewhere/O=Manske EIS/OU=Radius_Managment/CN=Manske Radius/emailAddress=xxx (the server certificate) V 14-02-17 13:16:54 Z 02 unknown /C=DE/ST=Somewhere/O=Manske EIS/OU=Radius_Managment/CN=User Name/emailAddress=xxx (one of the problematic user certificates) I tried it with check_crl = yes and no changes before the problem occurs: I updated openssl-packages from Internal Program Version: OpenSSL 1.0.0j also included the old version 0.9.7m also included the old version 0.9.8x to Internal Program Version: OpenSSL 1.0.1c also included the old version 0.9.8x But I did this over three days before the errors occured. In the meantime freeradius worked well. So, here is a shorten output of radiusd -X (I hope I do not shorten important things - btw, are there parts of such an debug output I should keep secret?) Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host 192.168.x.x port 2049, id=2, length=141 User-Name = "User Name" NAS-IP-Address = 192.168.x.x # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "User Name", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 0 length 19 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated [files] users: Matched entry User Name at line 8 [files] expand: Hello, %{User-Name} -> Hello, User Name ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] EAP Identity [eap] processing type md5 rlm_eap_md5: Issuing Challenge ++[eap] returns handled [eap] Request found, released from the list [eap] EAP NAK [eap] EAP-NAK asked for EAP-Type/tls [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 2 to 192.168.x.x port 2049 Reply-Message = "Hello, User Name" EAP-Message = 0x010200060d20 Message-Authenticator = 0x00000000000000000000000000xx State = 0x7d1f9f227c1d92c8e39xxxxxxxxx Finished request 1. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.x.x port 2049, id=2, length=227 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated [files] users: Matched entry User Name at line 8 [files] expand: Hello, %{User-Name} -> Hello, User Name ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS TLS Length 77 [tls] Length Included [tls] eaptls_verify returned 11 [tls] (other): before/accept initialization [tls] TLS_accept: before/accept initialization [tls] <<< TLS 1.0 Handshake [length 0048], ClientHello [tls] TLS_accept: SSLv3 read client hello A [tls] >>> TLS 1.0 Handshake [length 0031], ServerHello [tls] TLS_accept: SSLv3 write server hello A [tls] >>> TLS 1.0 Handshake [length 08bb], Certificate [tls] TLS_accept: SSLv3 write certificate A [tls] >>> TLS 1.0 Handshake [length 00b8], CertificateRequest [tls] TLS_accept: SSLv3 write certificate request A [tls] TLS_accept: SSLv3 flush data [tls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [tls] eaptls_process returned 13 [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS TLS Length 77 [tls] Length Included [tls] eaptls_verify returned 11 [tls] (other): before/accept initialization [tls] TLS_accept: before/accept initialization [tls] <<< TLS 1.0 Handshake [length 0048], ClientHello [tls] TLS_accept: SSLv3 read client hello A [tls] >>> TLS 1.0 Handshake [length 0031], ServerHello [tls] TLS_accept: SSLv3 write server hello A [tls] >>> TLS 1.0 Handshake [length 08bb], Certificate [tls] TLS_accept: SSLv3 write certificate A [tls] >>> TLS 1.0 Handshake [length 00b8], CertificateRequest [tls] TLS_accept: SSLv3 write certificate request A [tls] TLS_accept: SSLv3 flush data [tls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 2 to 192.168.x.x port 2049 Reply-Message = "Hello, User Name" EAP-Message = 0x010304000dc0000009b316030100310200002d030150e4ae0ed21d8 EAP-Message = 0x3017060355040313104d616e736b6520526164697573204341301e1 EAP-Message = 0xce7ab5f8c7edc84656371d677436108b21313e1ea308f55566b8684 EAP-Message = 0x25040c300a06082b06010505070301300d06092a864886f70d01010 EAP-Message = 0xb12f24c809d9d Message-Authenticator = 0x00000000000000000000000000000000 State = 0x7d1f9f227f1c92c8e3xxxxxx Finished request 2. Going to the next request [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated Sending Access-Challenge of id 2 to 192.168.x.x port 2049 Reply-Message = "Hello, User Name" EAP-Message = 0x010404000dc0000009b3301 EAP-Message = 0x3130323136313231325a17: Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] Received TLS ACK [tls] ACK handshake fragment handler [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 2 to 192.168.x.x port 2049 Reply-Message = "Hello, User Name" EAP-Message = 0x010404000dc0000009bxxxxxx EAP-Message = 0xfdf4cec951566e50d17 EAP-Message = 0xca21c0f495c75a3a13d EAP-Message = 0x01ff300d06092a86488 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x7d1f9f227e1b92c8e39 Finished request 3. Going to the next request and so on ... but here it might be important: # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] eaptls_verify returned 7 [tls] Done initial handshake [tls] <<< TLS 1.0 Handshake [length 03de], Certificate [tls] chain-depth=1, [tls] error=0 [tls] --> User-Name = User Name [tls] --> BUF-Name = Radius CA [tls] --> subject = /C=DE/ST=Somewhere/L=Somewhere/O=Manske EIS/OU=Radius_Managment/emailAddress=radius@xxxx [tls] --> issuer = /C=DE/ST=Somewhere/L=Somewhere/O=Manske EIS/OU=Radius_Managment/emailAddress=radius@xxxx [tls] --> verify return:1 --> verify error:num=7:certificate signature failure [tls] >>> TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert write:fatal:decrypt error TLS_accept: error in SSLv3 read client certificate B rlm_eap: SSL error error:04067084:rsa routines:RSA_EAY_PUBLIC_DECRYPT:data too large for modulus SSL: SSL_read failed inside of TLS (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Login incorrect (certificate signature failure): [User Name/<via Auth-Type = EAP>] (from client xxxx Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> User Name attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 6 for 2 seconds Going to the next request Waking up in 0.9 seconds. Waking up in 0.9 seconds. Sending delayed reject for request 6 Sending Access-Reject of id 2 to 192.168.x.x port 2049 TIIA, Stephan
Stephan Manske wrote:
first of all: this should not be a "how must I config my freeradius to work?" problem. These installation with these certificates and these config worked for over 8 month very well. And suddenly I got the problem.
OK.
changes before the problem occurs: I updated openssl-packages from
Internal Program Version: OpenSSL 1.0.0j also included the old version 0.9.7m also included the old version 0.9.8x
to
Internal Program Version: OpenSSL 1.0.1c
That might be the issue. It's hard to say. SSL is magic.
But I did this over three days before the errors occured. In the meantime freeradius worked well.
Maybe there's one client which *didn't* get login until after 3 days.
So, here is a shorten output of radiusd -X (I hope I do not shorten important things - btw, are there parts of such an debug output I should keep secret?)
Passwords, shared secrets.
[tls] --> verify return:1 --> verify error:num=7:certificate signature failure [tls] >>> TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert write:fatal:decrypt error TLS_accept: error in SSLv3 read client certificate B rlm_eap: SSL error error:04067084:rsa routines:RSA_EAY_PUBLIC_DECRYPT:data too large for modulus
That's an SSL error. It looks like the certificate being presented is wrong, or the client has made a mistake in SSL. I would suggest manually verifying the certificates using the "openssl" command-line tool. It may be that the signatures are broken. And the OpenSSL upgrade added code which checked for that, where the older version of OpenSSL didn't check. For SSL issues, we're completely at the mercy of OpenSSL. If it says "bad certificate", then no amount of poking FreeRADIUS will make it work. You've just got to create good certificates. Alan DeKok.
Am 22.01.2013, 22:19 Uhr, schrieb Alan DeKok <aland@deployingradius.com>:
Stephan Manske wrote:
to
Internal Program Version: OpenSSL 1.0.1c
That might be the issue. It's hard to say. SSL is magic.
But I did this over three days before the errors occured. In the meantime freeradius worked well.
Maybe there's one client which *didn't* get login until after 3 days.
regrettably no. All my certificate clients are affected. And there is at least one, namely my android, which connects every day. And this one has no problems for 3 days after update, and now it has the problem.
So, here is a shorten output of radiusd -X (I hope I do not shorten important things - btw, are there parts of such an debug output I should keep secret?)
Passwords, shared secrets.
What is about all this stuff: EAP-Message = 0x010304000dc0000009b31603010031020000 State = 0x7d1f9f227f1c92c8e3xxxxxx and so on?
[tls] --> verify return:1 --> verify error:num=7:certificate signature failure [tls] >>> TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert write:fatal:decrypt error TLS_accept: error in SSLv3 read client certificate B rlm_eap: SSL error error:04067084:rsa routines:RSA_EAY_PUBLIC_DECRYPT:data too large for modulus
That's an SSL error. It looks like the certificate being presented is wrong, or the client has made a mistake in SSL.
Am I right when I suggest this certificate B is the CA certificate? The certificate A has no problems (in the majority of cases I found via google cert A was the problem).
I would suggest manually verifying the certificates using the "openssl" command-line tool. It may be that the signatures are broken.
any hint where I can found more to read about what I should test? Which parameters I have to use with openssl command?
And the OpenSSL upgrade added code which checked for that, where the older version of OpenSSL didn't check.
For SSL issues, we're completely at the mercy of OpenSSL. If it says "bad certificate", then no amount of poking FreeRADIUS will make it work. You've just got to create good certificates.
And there is no way to tell freeradius to tell openssl to give more debug informations in this moment? Ciao, Stephan
Stephan Manske wrote:
regrettably no. All my certificate clients are affected. And there is at least one, namely my android, which connects every day. And this one has no problems for 3 days after update, and now it has the problem.
Well, it's not a FreeRADIUS issue. The error is in the SSL code, or in the certificates.
What is about all this stuff:
EAP-Message = 0x010304000dc0000009b31603010031020000 State = 0x7d1f9f227f1c92c8e3xxxxxx
and so on?
There's nothing secret in that.
Am I right when I suggest this certificate B is the CA certificate?
I'm not really sure... the OpenSSL messages are vague.
The certificate A has no problems (in the majority of cases I found via google cert A was the problem).
I would suggest manually verifying the certificates using the "openssl" command-line tool. It may be that the signatures are broken.
any hint where I can found more to read about what I should test? Which parameters I have to use with openssl command?
See raddb/certs/Makefile, it's all there.
And there is no way to tell freeradius to tell openssl to give more debug informations in this moment?
That *is* all of the information OpenSSL can provide. Alan DeKok.
Am 22.01.2013, 23:44 Uhr, schrieb Alan DeKok <aland@deployingradius.com>:
Stephan Manske wrote:
any hint where I can found more to read about what I should test? Which parameters I have to use with openssl command?
See raddb/certs/Makefile, it's all there.
OK, and I will try my luck at Openssl community.
And there is no way to tell freeradius to tell openssl to give more debug informations in this moment?
That *is* all of the information OpenSSL can provide.
:-( Thanks, Stephan
Am 22.01.2013, 22:19 Uhr, schrieb Alan DeKok <aland@deployingradius.com>:
Stephan Manske wrote:
[tls] --> verify return:1 --> verify error:num=7:certificate signature failure [tls] >>> TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert write:fatal:decrypt error TLS_accept: error in SSLv3 read client certificate B rlm_eap: SSL error error:04067084:rsa routines:RSA_EAY_PUBLIC_DECRYPT:data too large for modulus
That's an SSL error. It looks like the certificate being presented is wrong, or the client has made a mistake in SSL.
I think I found the issue: Yes, it is a ssl problem, the ca.key and all the certs are incompatible. And no, it is not only a ssl problem, it is a freeradius problem, too: I made a new client certificate and this can be verified: #openssl verify -verbose -CAfile ca.pem 0B.pem 0B.pem: OK I made a next one: openssl verify -verbose -CAfile ca.pem 0C.pem 0C.pem: OK but, the last one now: )# openssl verify -verbose -CAfile ca.pem 0B.pem 0B.pem: C = DE, ST = Somewhere, O = Manske EIS, OU = Radius_Managment, CN = xxxx Smart, emailAddress = user@mail.example error 7 at 0 depth lookup:certificate signature failure 3074770568:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100: 3074770568:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:721: 3074770568:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: IMHO these patch https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f96... with +ca.key ca.pem: ca.cnf index.txt serial makes ca.key dependant to the date of index.txt and serial Both files are updated every time a new client cert is build. IMHO. And so, I have a look at the cert generation: # touch serial # make client openssl req -new -out client.csr -keyout client.key -config ./client.cnf Generating a 2048 bit RSA private key .....+++ ...........................................................+++ writing new private key to 'client.key' ----- openssl req -new -x509 -keyout ca.key -out ca.pem \ -days `grep default_days ca.cnf | sed 's/.*=//;s/^ *//'` -config ./ca.cnf Generating a 2048 bit RSA private key .............................................................+++ ........................................................................................+++ writing new private key to 'ca.key' # touch serial # make client openssl req -new -x509 -keyout ca.key -out ca.pem \ -days `grep default_days ca.cnf | sed 's/.*=//;s/^ *//'` -config ./ca.cnf Generating a 2048 bit RSA private key .........................................................................................+++ ..................+++ writing new private key to 'ca.key' ----- and so on ... With this new generated ca.key the older certs are not able to validate anymore. But I do not think, that it is wanted to generate a new ca.key every time, or am I wrong? This looks similar to https://github.com/FreeRADIUS/freeradius-server/commit/7394b88e4725d47727338... 69 -server.crt: server.csr ca.key ca.pem index.txt serial 69 +server.crt: server.csr ca.key ca.pem before your patch I made this with an order-only prerequisites "|" in my private source: server.crt: server.csr ca.key ca.pem | index.txt serial I did this for the mentioned parts now, too ###################################################################### # # Create a new self-signed CA certificate # ###################################################################### ca.key ca.pem: ca.cnf | index.txt serial openssl req -new -x509 -keyout ca.key -out ca.pem \ -days $(CA_DEFAULT_DAYS) -config ./ca.cnf and it works: # touch serial # make client openssl req -new -out client.csr -keyout client.key -config ./client.cnf Generating a 2048 bit RSA private key .....................+++ .......+++ writing new private key to 'client.key' ----- openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key `grep output_password ca.cnf | sed 's/.*=//;s/^ *//'` -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf Using configuration from ./client.cnf Check that the request matches the signature Signature ok ... # touch serial # make client openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key `grep output_password ca.cnf | sed 's/.*=//;s/^ *//'` -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf Using configuration from ./client.cnf Check that the request matches the signature Signature ok Certificate Details: even: # touch serial # make ca.key make: `ca.key' is up to date. I hope my thoughts are right and helpfull. Ciao, Stephan
Am 23.01.2013, 19:53 Uhr, schrieb Stephan Manske <gmane-reply@stephan.manske-net.de>:
Yes, it is a ssl problem, the ca.key and all the certs are incompatible.
And no, it is not only a ssl problem, it is a freeradius problem, too:
Unless the makefile in certs is provided by openssl, but I think this is freeradius stuff, or? Ciao, Stephan
Stephan Manske wrote:
Unless the makefile in certs is provided by openssl, but I think this is freeradius stuff, or?
The Makefile I pointed to was written by me. It runs OpenSSL scripts to create certificates. It uses sample configurations written by me. It works for *everyone* else. If you didn't use the Makefiles to create the certs, then don't blame FreeRADIUS. If you did use them, then blame OpenSSL for creating certificates it can't read. FreeRADIUS doesn't implement SSL. OpenSSL does. FreeRADIUS doesn't parse certs. OpenSSL does. Is that clear enough? Alan DeKok.
Am 23.01.2013, 21:03 Uhr, schrieb Alan DeKok <aland@deployingradius.com>:
Stephan Manske wrote:
Unless the makefile in certs is provided by openssl, but I think this is freeradius stuff, or?
It works for *everyone* else. If you didn't use the Makefiles to create the certs, then don't blame FreeRADIUS. If you did use them,
I do not blame anybody. I have a problem using the makefile, I am only a little user and I tried to figure out, what is the problem. And I found a patch https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f96... that makes these trouble to me, so I report this. No blame, no offense.
FreeRADIUS doesn't implement SSL. OpenSSL does. FreeRADIUS doesn't parse certs. OpenSSL does.
Is that clear enough?
tell me, if I am wrong: (again, no offense! I do not have the deep look into this stuff, I can only ask questions at my level of understanding the code) the actual makefile has: ca.key ca.pem: ca.cnf index.txt serial this makes ca.key dependant to the date of index.txt and serial. Right? Both files are updated every time a new client cert is build. Right? So, makefile thinks ca.key is outdated and should be renewed. (before the patch, makefile does not care about index.txt and serial) Right? If yes, please read my posting from 19:53:53 benevolently. Thanks, Stephan
On 01/23/2013 01:53 PM, Stephan Manske wrote:
IMHO these patch https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f96...
with
+ca.key ca.pem: ca.cnf index.txt serial
makes ca.key dependant to the date of index.txt and serial
Both files are updated every time a new client cert is build. IMHO.
Good catch! Yes, every time you generate a client cert both the database (index.txt) and the serial number file are updated. The database file keeps a record of every cert issued by the CA. The serial file is used so the CA knows the next serial number to use. The cert generation only works once, the next client cert issue causes a new CA key/cert to be generated. But there is another problem as well. The client.cnf file embeds the cert subject name. Apparently the openssl ca command will not update the database if there already is a cert with the same subject, which there will be unless you edit the client.cnf file. This causes the ca command to fail. It doesn't matter if the cert with the duplicate subject has a different serial number. As for why in different circumstances you've seen openssl emit the error about incomplete data my best guess is the client files might have be corrupted when the ca command failed. If it were only a CA key change issue you should have just gotten a bad signature verification failure. HTH, John -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Stephan Manske wrote:
I think I found the issue: ... makes ca.key dependant to the date of index.txt and serial
Both files are updated every time a new client cert is build. IMHO.
OK. That's a better explanation than "FreeRADIUS is wrong". There's a fix on github, which will be in 2.2.1. Alan DeKok.
Am 23.01.2013, 21:13 Uhr, schrieb Alan DeKok <aland@deployingradius.com>:
Stephan Manske wrote:
I think I found the issue: ... makes ca.key dependant to the date of index.txt and serial
Both files are updated every time a new client cert is build. IMHO.
OK. That's a better explanation than "FreeRADIUS is wrong".
There's a fix on github, which will be in 2.2.1.
ca.key ca.pem: ca.cnf @[ -f index.txt ] || $(MAKE) index.txt @[ -f serial ] || $(MAKE) serial openssl req -new -x509 -keyout ca.key -out ca.pem \ -days $(CA_DEFAULT_DAYS) -config ./ca.cnf I am only a make noob, but is there a reason not to use order-only-prerequisites? "Occasionally, however, you have a situation where you want to impose a specific ordering on the rules to be invoked without forcing the target to be updated if one of those rules is executed. In that case, you want to define order-only prerequisites. Order-only prerequisites can be specified by placing a pipe symbol (|) in the prerequisites list: any prerequisites to the left of the pipe symbol are normal; any prerequisites to the right are order-only: targets : normal-prerequisites | order-only-prerequisites" Does this work with specific make commands only? So you cannot use it in freeradius to be compatible? Ciao, Stephan
Hi,
IMHO these patch https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f96...
with
+ca.key ca.pem: ca.cnf index.txt serial
you stated earlier that you didnt touch freeradius...that all you did was update OpenSSL to the latest version.... to be affected by any change to certificate makefiles etc you would have had to update/play with freeradius too. which you stated you didnt do. alan
Am 23.01.2013, 21:23 Uhr, schrieb <A.L.M.Buxey@lboro.ac.uk>:
IMHO these patch https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f96...
with
+ca.key ca.pem: ca.cnf index.txt serial
you stated earlier that you didnt touch freeradius...that all you did was update OpenSSL to the latest version.... to be affected by any change to certificate makefiles etc you would have had to update/play with freeradius too. which you stated you didnt do.
yes, I updated my freeradius installation to 2.2.0. But I did this _months_ ago. My fault, not to think about an update months ago. Really sorry. So, it was a coexistence: all worked fine, then I updated openssl, made a new client certificate to test it (unfortunately the first time for months) and from now on my older certificates gave me ssl errors. So it looks to me that there a relation to this ssl update. Ciao, Stephan
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
John Dennis -
Stephan Manske