AW: AW: AW: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
If I understand this logs rights, the error happening on ca certificate? ... Mon Dec 18 14:41:44 2017 : Debug: (2) eap_tls: TLS-Cert-Subject := "/C=DE/O=Deutsches BiomasseForschungsZentrum gemeinnuetzige GmbH/OU=IT/CN=CAPF-1b0db5b4/ST=Sachsen/L=Leipzig" Mon Dec 18 14:41:44 2017 : Debug: (2) eap_tls: TLS-Cert-Issuer := "/C=DE/O=Deutsches BiomasseForschungsZentrum gemeinnuetzige GmbH/OU=IT/CN=CAPF-1b0db5b4/ST=Sachsen/L=Leipzig" Mon Dec 18 14:41:44 2017 : Debug: (2) eap_tls: TLS-Cert-Common-Name := "CAPF-1b0db5b4" Mon Dec 18 14:41:44 2017 : ERROR: (2) eap_tls: SSL says error 26 : unsupported certificate purpose Mon Dec 18 14:41:44 2017 : Debug: Ignoring cbtls_msg call with pseudo content type 256, version 0 Mon Dec 18 14:41:44 2017 : Debug: (2) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate Mon Dec 18 14:41:44 2017 : ERROR: (2) eap_tls: TLS Alert write:fatal:unsupported certificate Mon Dec 18 14:41:44 2017 : Error: tls: TLS_accept: Error in error Mon Dec 18 14:41:44 2017 : ERROR: (2) eap_tls: Failed in __FUNCTION__ (SSL_read): ../ssl/statem/statem_srvr.c[2896]:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Mon Dec 18 14:41:44 2017 : ERROR: (2) eap_tls: System call (I/O) error (-1) ... Robert
On Dec 19, 2017, at 5:22 AM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
If I understand this logs rights, the error happening on ca certificate?
No. They're about the server certificate.
Mon Dec 18 14:41:44 2017 : ERROR: (2) eap_tls: SSL says error 26 : unsupported certificate purpose
As I said before, OpenSSL doesn't like the X509 OIDs in the certificate. The "openssl verify" returns OK, because it verifies the cert for a different purpose. No amount of poking FreeRADIUS will fix the OpenSSL code which sanity checks the certificate. Your choices are: a) fix the Cisco equipment to produce certs that OpenSSL likes b) fix the new version OpenSSL to remove this extra sanity checking c) downgrade the whole OS + OpenSSL to a version of OpenSSL which doesn't have this extra check. You can post messages to this list all you want, but nothing we can do to help. We CANNOT work around this in FreeRADIUS, because it's an OpenSSL limitation. Alan DeKok.
Hi. Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. Here's client cert from capture (RADIUS protocol dump, frame #10): Certificate: 30820345308202aea003020102020200f1300d06092a8648... (id-at-commonName=SEP64A0E7147412,id-at-organizationalUnitName=IT,id-at-organizationName=Deutsches BiomasseForschungsZentrum geme,id-at-countryName=DE) signedCertificate version: v3 (2) serialNumber: 241 And this is how it is presented in logs: ... Tue Dec 19 17:03:01 2017 : Debug: (21) Received Access-Request Id 32 from 172.24.3.197:1645 to 172.28.0.65:1912 length 1619 Tue Dec 19 17:03:01 2017 : Debug: (21) User-Name = "CP-7965G-SEP0008308BD7A4" Tue Dec 19 17:03:01 2017 : Debug: (21) Service-Type = Framed-User ... Tue Dec 19 17:03:02 2017 : Debug: (22) eap_tls: TLS-Cert-Serial := "5871a15a20dc203cceb13b568ad905f9" Tue Dec 19 17:03:02 2017 : Debug: (22) eap_tls: TLS-Cert-Expiration := "220309050842Z" Tue Dec 19 17:03:02 2017 : Debug: (22) eap_tls: TLS-Cert-Subject := "/C=DE/O=Deutsches BiomasseForschungsZentrum gemeinnuetzige GmbH/OU=IT/CN=CAPF-1b0db5b4/ST=Sachsen/L=Leipzig" Tue Dec 19 17:03:02 2017 : Debug: (22) eap_tls: TLS-Cert-Issuer := "/C=DE/O=Deutsches BiomasseForschungsZentrum gemeinnuetzige GmbH/OU=IT/CN=CAPF-1b0db5b4/ST=Sachsen/L=Leipzig" Tue Dec 19 17:03:02 2017 : Debug: (22) eap_tls: TLS-Cert-Common-Name := "CAPF-1b0db5b4" ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration... On 19.12.2017 19:15, Alan DeKok wrote:
On Dec 19, 2017, at 5:22 AM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
If I understand this logs rights, the error happening on ca certificate? No.
They're about the server certificate.
Mon Dec 18 14:41:44 2017 : ERROR: (2) eap_tls: SSL says error 26 : unsupported certificate purpose As I said before, OpenSSL doesn't like the X509 OIDs in the certificate.
The "openssl verify" returns OK, because it verifies the cert for a different purpose.
No amount of poking FreeRADIUS will fix the OpenSSL code which sanity checks the certificate.
Your choices are:
a) fix the Cisco equipment to produce certs that OpenSSL likes
b) fix the new version OpenSSL to remove this extra sanity checking
c) downgrade the whole OS + OpenSSL to a version of OpenSSL which doesn't have this extra check.
You can post messages to this list all you want, but nothing we can do to help. We CANNOT work around this in FreeRADIUS, because it's an OpenSSL limitation.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Boris Lytochkin Yandex NOC +7 (495) 739 70 00 ext. 7671
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration...
EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence. If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert. When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial" Alan DeKok.
Hello Alan, so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c? 495 /*- 496 * CA checks common to all purposes 497 * return codes: 498 * 0 not a CA 499 * 1 is a CA 500 * 2 basicConstraints absent so "maybe" a CA 501 * 3 basicConstraints absent but self signed V1. 502 * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. 503 */ 504 505 static int check_ca(const X509 *x) 506 { 507 /* keyUsage if present should allow cert signing */ 508 if (ku_reject(x, KU_KEY_CERT_SIGN)) 509 return 0; 510 if (x->ex_flags & EXFLAG_BCONS) { 511 if (x->ex_flags & EXFLAG_CA) 512 return 1; 513 /* If basicConstraints says not a CA then say so */ 514 else 515 return 0; 516 } else { 517 /* we support V1 roots for... uh, I don't really know why. */ 518 if ((x->ex_flags & V1_ROOT) == V1_ROOT) 519 return 3; 520 /* 521 * If key usage present it must have certSign so tolerate it 522 */ 523 else if (x->ex_flags & EXFLAG_KUSAGE) 524 return 4; 525 /* Older certificates could have Netscape-specific CA types */ 526 else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA) 527 return 5; 528 /* can this still be regarded a CA certificate? I doubt it */ 529 return 0; 530 } 531 } But it is documented as a warning, not an error!? It is possible, to add an workarround for mistake in conf / tls.c <DIFF tls.c> if (!my_ok && (conf->allow_expired_crl) && (err == X509_V_ERR_CRL_HAS_EXPIRED)) { my_ok = 1; X509_STORE_CTX_set_error( ctx, 0 ); } + if (!my_ok && + (conf->allow_wrong_purposed) && + (err == X509_V_ERR_INVALID_PURPOSE)) { + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + } if (!my_ok) { </DIFF> I hope, my mail not sounds arogant :-( Robert -----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freeradius.org] Im Auftrag von Alan DeKok Gesendet: Dienstag, 19. Dezember 2017 18:49 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration...
EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence. If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert. When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial" Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 19, 2017, at 5:09 PM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c?
Yes.
But it is documented as a warning, not an error!?
The return codes tell the application about the certificate. They're not errors or warnings.
It is possible, to add an workarround for mistake in conf / tls.c
It's possible to change FreeRADIUS to do anything. The question is whether it's a good idea. In this case, I don't think so. For one, "invalid purpose" is an error which I've never seen before, in 20 years of working with FreeRADIUS. It strongly indicates that there's something unusual about the certificates. For another, working around "invalid purpose" is a bad idea. Those checks are there for a reason. Avoiding them means you're essentially ignoring the certificate contents. You're free to put the patch into your local version of FreeRADIUS. But until it's clear that the patch won't cause problems... it can't go into the main distribution.
I hope, my mail not sounds arogant :-(
Nope. Alan DeKok.
Hi. It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing. See http://www.alvestrand.no/objectid/2.5.29.19.html On 20.12.2017 1:09, Gladewitz, Robert via Freeradius-Users wrote:
Hello Alan,
so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c?
495 /*- 496 * CA checks common to all purposes 497 * return codes: 498 * 0 not a CA 499 * 1 is a CA 500 * 2 basicConstraints absent so "maybe" a CA 501 * 3 basicConstraints absent but self signed V1. 502 * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. 503 */ 504 505 static int check_ca(const X509 *x) 506 { 507 /* keyUsage if present should allow cert signing */ 508 if (ku_reject(x, KU_KEY_CERT_SIGN)) 509 return 0; 510 if (x->ex_flags & EXFLAG_BCONS) { 511 if (x->ex_flags & EXFLAG_CA) 512 return 1; 513 /* If basicConstraints says not a CA then say so */ 514 else 515 return 0; 516 } else { 517 /* we support V1 roots for... uh, I don't really know why. */ 518 if ((x->ex_flags & V1_ROOT) == V1_ROOT) 519 return 3; 520 /* 521 * If key usage present it must have certSign so tolerate it 522 */ 523 else if (x->ex_flags & EXFLAG_KUSAGE) 524 return 4; 525 /* Older certificates could have Netscape-specific CA types */ 526 else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA) 527 return 5; 528 /* can this still be regarded a CA certificate? I doubt it */ 529 return 0; 530 } 531 }
But it is documented as a warning, not an error!?
It is possible, to add an workarround for mistake in conf / tls.c
<DIFF tls.c> if (!my_ok && (conf->allow_expired_crl) && (err == X509_V_ERR_CRL_HAS_EXPIRED)) { my_ok = 1; X509_STORE_CTX_set_error( ctx, 0 ); }
+ if (!my_ok && + (conf->allow_wrong_purposed) && + (err == X509_V_ERR_INVALID_PURPOSE)) { + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + }
if (!my_ok) {
</DIFF>
I hope, my mail not sounds arogant :-(
Robert
-----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freeradius.org] Im Auftrag von Alan DeKok Gesendet: Dienstag, 19. Dezember 2017 18:49 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration... EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence.
If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert.
When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial"
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Boris Lytochkin Yandex NOC +7 (495) 739 70 00 ext. 7671
On Dec 20, 2017, at 1:51 AM, Boris Lytochkin <lytboris@yandex-team.ru> wrote:
Hi.
It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing.
If that's the case then yes, the certs are broken. And hell will freeze over before I update FreeRADIUS to allow broken CA certs. Alan DeKok.
Hello Alan, is there a possible way, to ignore all certificates in ttls and send an accept?? Robert -----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freeradius.org] Im Auftrag von Alan DeKok Gesendet: Mittwoch, 20. Dezember 2017 13:31 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 20, 2017, at 1:51 AM, Boris Lytochkin <lytboris@yandex-team.ru> wrote:
Hi.
It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing.
If that's the case then yes, the certs are broken. And hell will freeze over before I update FreeRADIUS to allow broken CA certs. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
is there a possible way, to ignore all certificates in ttls and send an accept??
paraphrased, you ask "Is there a way to throw overboard all security, and to make my users susceptible to MITM attacks?" Surprisingly, the answer is "Yes, that's the default behaviour." A non-configured supplicant will typically accept all certificates thrown at it, at best with a UI question like "Do you think that cert is okay?" That's a client-side problem though - FreeRADIUS always needs to *send* a server certificate. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi, i can not export an new ca infrastructure on one time, because it will be have to many phone clients, there lost the connection!. My Idea is, that we ignore all client certificates (server certificate sending will be ok) for the time we published the new certificates on all cisco clients. At the moment, i configures Auth-Type = eap8021xciscophone in my database and eap8021xciscophone is configured as ttls including this wrong ca infrastructure. So, on which part I can send the accept to the switch, without check the client certificate and ca?? The autorize prozess is correctly done. Robert -----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 11:08 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hi,
is there a possible way, to ignore all certificates in ttls and send an accept??
paraphrased, you ask "Is there a way to throw overboard all security, and to make my users susceptible to MITM attacks?" Surprisingly, the answer is "Yes, that's the default behaviour." A non-configured supplicant will typically accept all certificates thrown at it, at best with a UI question like "Do you think that cert is okay?" That's a client-side problem though - FreeRADIUS always needs to *send* a server certificate. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi, do you realise that such a setup will let EVERYBODY into your network? Including all the bad guys? Or do the phones have an additional (strong) username/password? Stefan Am 21.12.2017 um 11:50 schrieb Gladewitz, Robert:
Hi,
i can not export an new ca infrastructure on one time, because it will be have to many phone clients, there lost the connection!.
My Idea is, that we ignore all client certificates (server certificate sending will be ok) for the time we published the new certificates on all cisco clients.
At the moment, i configures Auth-Type = eap8021xciscophone in my database and eap8021xciscophone is configured as ttls including this wrong ca infrastructure.
So, on which part I can send the accept to the switch, without check the client certificate and ca?? The autorize prozess is correctly done.
Robert
-----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 11:08 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
Hi,
is there a possible way, to ignore all certificates in ttls and send an accept??
paraphrased, you ask "Is there a way to throw overboard all security, and to make my users susceptible to MITM attacks?"
Surprisingly, the answer is "Yes, that's the default behaviour." A non-configured supplicant will typically accept all certificates thrown at it, at best with a UI question like "Do you think that cert is okay?"
That's a client-side problem though - FreeRADIUS always needs to *send* a server certificate.
Greetings,
Stefan Winter
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette
Tel: +352 424409 1 Fax: +352 422473
PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi, No, i check the calling-station-id bevor in a database in autorize. And only the voice-vlan will be happening. Robert -----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 12:33 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de> Cc: freeradius-users@lists.freeradius.org Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hi, do you realise that such a setup will let EVERYBODY into your network? Including all the bad guys? Or do the phones have an additional (strong) username/password? Stefan Am 21.12.2017 um 11:50 schrieb Gladewitz, Robert:
Hi,
i can not export an new ca infrastructure on one time, because it will be have to many phone clients, there lost the connection!.
My Idea is, that we ignore all client certificates (server certificate sending will be ok) for the time we published the new certificates on all cisco clients.
At the moment, i configures Auth-Type = eap8021xciscophone in my database and eap8021xciscophone is configured as ttls including this wrong ca infrastructure.
So, on which part I can send the accept to the switch, without check the client certificate and ca?? The autorize prozess is correctly done.
Robert
-----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 11:08 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
Hi,
is there a possible way, to ignore all certificates in ttls and send an accept??
paraphrased, you ask "Is there a way to throw overboard all security, and to make my users susceptible to MITM attacks?"
Surprisingly, the answer is "Yes, that's the default behaviour." A non-configured supplicant will typically accept all certificates thrown at it, at best with a UI question like "Do you think that cert is okay?"
That's a client-side problem though - FreeRADIUS always needs to *send* a server certificate.
Greetings,
Stefan Winter
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette
Tel: +352 424409 1 Fax: +352 422473
PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Dec 21, 2017, at 5:50 AM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
i can not export an new ca infrastructure on one time, because it will be have to many phone clients, there lost the connection!.
My Idea is, that we ignore all client certificates (server certificate sending will be ok) for the time we published the new certificates on all cisco clients.
You are free to edit the source. You can make it do anything you want it to do. Alan DeKok.
Hello Alan, yes, but may someone have may a solution without programming? Robert -----Ursprüngliche Nachricht----- Von: Alan DeKok [mailto:aland@deployingradius.com] Gesendet: Donnerstag, 21. Dezember 2017 14:14 An: Gladewitz, Robert <Robert.Gladewitz@dbfz.de>; FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate On Dec 21, 2017, at 5:50 AM, Gladewitz, Robert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
i can not export an new ca infrastructure on one time, because it will be
have to many phone clients, there lost the connection!.
My Idea is, that we ignore all client certificates (server certificate
sending will be ok) for the time we published the new certificates on all cisco clients. You are free to edit the source. You can make it do anything you want it to do. Alan DeKok.
On Dec 21, 2017, at 8:17 AM, Gladewitz, Robert <Robert.Gladewitz@dbfz.de> wrote:
yes, but may someone have may a solution without programming?
<sigh> You're doing it again. If there WAS a solution without programming, the documentation would say how to do it. But when I tell you (multiple times) you need to edit the source, your reply is "really? Are you sure?" I'm not lying to you. In case you didn't notice, asking a question and then arguing with the answer is ignorant, obnoxious, arrogant, and rude. Stop it. Alan DeKok.
Hi,
It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing.
Out of curiosity (I didn't think Cisco can be so stupid to make CAs which aren't actually CAs...) I searched, and my search engine of choice gave me this link: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut82798/?referring_site=bug... (needs free registration to view) So, indeed, Cisco WAS that stupid. For an extended amount of time and multiple major version releases. FWIW, if the OP can upgrade his system to release 11.5 and re-generate the CAPF CA, then he should get a real CA. Which then makes tinkering with source code obsolete. (If the answer is that you need to edit the source code, then you are asking the wrong question :-) ) Greetings, Stefan Winter Am 20.12.2017 um 07:51 schrieb Boris Lytochkin:
Hi.
See http://www.alvestrand.no/objectid/2.5.29.19.html
On 20.12.2017 1:09, Gladewitz, Robert via Freeradius-Users wrote:
Hello Alan,
so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c?
495 /*- 496 * CA checks common to all purposes 497 * return codes: 498 * 0 not a CA 499 * 1 is a CA 500 * 2 basicConstraints absent so "maybe" a CA 501 * 3 basicConstraints absent but self signed V1. 502 * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. 503 */ 504 505 static int check_ca(const X509 *x) 506 { 507 /* keyUsage if present should allow cert signing */ 508 if (ku_reject(x, KU_KEY_CERT_SIGN)) 509 return 0; 510 if (x->ex_flags & EXFLAG_BCONS) { 511 if (x->ex_flags & EXFLAG_CA) 512 return 1; 513 /* If basicConstraints says not a CA then say so */ 514 else 515 return 0; 516 } else { 517 /* we support V1 roots for... uh, I don't really know why. */ 518 if ((x->ex_flags & V1_ROOT) == V1_ROOT) 519 return 3; 520 /* 521 * If key usage present it must have certSign so tolerate it 522 */ 523 else if (x->ex_flags & EXFLAG_KUSAGE) 524 return 4; 525 /* Older certificates could have Netscape-specific CA types */ 526 else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA) 527 return 5; 528 /* can this still be regarded a CA certificate? I doubt it */ 529 return 0; 530 } 531 }
But it is documented as a warning, not an error!?
It is possible, to add an workarround for mistake in conf / tls.c
<DIFF tls.c> if (!my_ok && (conf->allow_expired_crl) && (err == X509_V_ERR_CRL_HAS_EXPIRED)) { my_ok = 1; X509_STORE_CTX_set_error( ctx, 0 ); }
+ if (!my_ok && + (conf->allow_wrong_purposed) && + (err == X509_V_ERR_INVALID_PURPOSE)) { + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + } if (!my_ok) {
</DIFF>
I hope, my mail not sounds arogant :-(
Robert
-----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freeradius.org] Im Auftrag von Alan DeKok Gesendet: Dienstag, 19. Dezember 2017 18:49 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration... EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence.
If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert.
When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial"
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hello, in first discusion, the errors seems tob e on a wrong ca certificate. Now, all certifices a changed an the errror still happening: <SNIP: DEBUG> (69) eap_tls: Continuing EAP-TLS (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes (69) eap_tls: Got complete TLS record (1432 bytes) (69) eap_tls: [eaptls verify] = length included (69) eap_tls: TLS_accept: SSLv3/TLS write server done (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate (69) eap_tls: Creating attributes from certificate OIDs (69) eap_tls: TLS-Cert-Serial := "1009" (69) eap_tls: TLS-Cert-Expiration := "380111125719Z" (69) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" (69) eap_tls: TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA INTERN ROOT/emailAddress=support@dbfz.de" (69) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" (69) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate tls: TLS_accept: Error in error (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed (69) eap_tls: ERROR: System call (I/O) error (-1) (69) eap_tls: ERROR: TLS receive handshake failed during operation (69) eap_tls: ERROR: [eaptls process] = fail </DEBUG> openssl -verify have no warning, if I do cert check manually. Fo testing, I append the certs. # openssl verify -verbose -CAfile /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem SEP64A0E714844E-L1.pem # SEP64A0E714844E-L1.pem: OK Regards Robert -----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 14:52 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>; Boris Lytochkin <lytboris@yandex-team.ru>; Gladewitz, Robert <Robert.Gladewitz@dbfz.de> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hi,
It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing.
Out of curiosity (I didn't think Cisco can be so stupid to make CAs which aren't actually CAs...) I searched, and my search engine of choice gave me this link: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut82798/?referring_site=bug... (needs free registration to view) So, indeed, Cisco WAS that stupid. For an extended amount of time and multiple major version releases. FWIW, if the OP can upgrade his system to release 11.5 and re-generate the CAPF CA, then he should get a real CA. Which then makes tinkering with source code obsolete. (If the answer is that you need to edit the source code, then you are asking the wrong question :-) ) Greetings, Stefan Winter Am 20.12.2017 um 07:51 schrieb Boris Lytochkin:
Hi.
See http://www.alvestrand.no/objectid/2.5.29.19.html
On 20.12.2017 1:09, Gladewitz, Robert via Freeradius-Users wrote:
Hello Alan,
so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c?
495 /*- 496 * CA checks common to all purposes 497 * return codes: 498 * 0 not a CA 499 * 1 is a CA 500 * 2 basicConstraints absent so "maybe" a CA 501 * 3 basicConstraints absent but self signed V1. 502 * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. 503 */ 504 505 static int check_ca(const X509 *x) 506 { 507 /* keyUsage if present should allow cert signing */ 508 if (ku_reject(x, KU_KEY_CERT_SIGN)) 509 return 0; 510 if (x->ex_flags & EXFLAG_BCONS) { 511 if (x->ex_flags & EXFLAG_CA) 512 return 1; 513 /* If basicConstraints says not a CA then say so */ 514 else 515 return 0; 516 } else { 517 /* we support V1 roots for... uh, I don't really know why. */ 518 if ((x->ex_flags & V1_ROOT) == V1_ROOT) 519 return 3; 520 /* 521 * If key usage present it must have certSign so tolerate it 522 */ 523 else if (x->ex_flags & EXFLAG_KUSAGE) 524 return 4; 525 /* Older certificates could have Netscape-specific CA types */ 526 else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA) 527 return 5; 528 /* can this still be regarded a CA certificate? I doubt it */ 529 return 0; 530 } 531 }
But it is documented as a warning, not an error!?
It is possible, to add an workarround for mistake in conf / tls.c
<DIFF tls.c> if (!my_ok && (conf->allow_expired_crl) && (err == X509_V_ERR_CRL_HAS_EXPIRED)) { my_ok = 1; X509_STORE_CTX_set_error( ctx, 0 ); }
+ if (!my_ok && + (conf->allow_wrong_purposed) && + (err == X509_V_ERR_INVALID_PURPOSE)) { + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + }
if (!my_ok) {
</DIFF>
I hope, my mail not sounds arogant :-(
Robert
-----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freer adius.org] Im Auftrag von Alan DeKok Gesendet: Dienstag, 19. Dezember 2017 18:49 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration... EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence.
If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert.
When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial"
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
I forget a higher debuglevel. What mean: in __FUNCTION__ (SSL_read): ../ssl/statem/statem_srvr.c[2896]:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed ??? <SNIP> Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Continuing EAP-TLS Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Peer sent flags --L Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Peer indicated complete TLS record size will be 1432 bytes Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Got complete TLS record (1432 bytes) Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: [eaptls verify] = length included Fri Jan 19 11:35:32 2018 : Debug: Ignoring cbtls_msg call with pseudo content type 256, version 0 Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS_accept: SSLv3/TLS write server done Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: Creating attributes from certificate OIDs Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Serial := "1009" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Expiration := "380111125719Z" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA INTERN ROOT/emailAddress=support@dbfz.de" Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: SSL says error 26 : unsupported certificate purpose Fri Jan 19 11:35:32 2018 : Debug: Ignoring cbtls_msg call with pseudo content type 256, version 0 Fri Jan 19 11:35:32 2018 : Debug: (3) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: TLS Alert write:fatal:unsupported certificate Fri Jan 19 11:35:32 2018 : Error: tls: TLS_accept: Error in error Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: Failed in __FUNCTION__ (SSL_read): ../ssl/statem/statem_srvr.c[2896]:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: System call (I/O) error (-1) Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: TLS receive handshake failed during operation Fri Jan 19 11:35:32 2018 : ERROR: (3) eap_tls: [eaptls process] = fail Fri Jan 19 11:35:32 2018 : ERROR: (3) eap8021xciscophone: Failed continuing EAP TLS (13) session. EAP sub-module failed </SNIP> -----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freeradius.org] Im Auftrag von Gladewitz, Robert via Freeradius-Users Gesendet: Freitag, 19. Januar 2018 10:28 An: freeradius-users@lists.freeradius.org Betreff: AW: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hello, in first discusion, the errors seems tob e on a wrong ca certificate. Now, all certifices a changed an the errror still happening: <SNIP: DEBUG> (69) eap_tls: Continuing EAP-TLS (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes (69) eap_tls: Got complete TLS record (1432 bytes) (69) eap_tls: [eaptls verify] = length included (69) eap_tls: TLS_accept: SSLv3/TLS write server done (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate (69) eap_tls: Creating attributes from certificate OIDs (69) eap_tls: TLS-Cert-Serial := "1009" (69) eap_tls: TLS-Cert-Expiration := "380111125719Z" (69) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" (69) eap_tls: TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA INTERN ROOT/emailAddress=support@dbfz.de" (69) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" (69) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate tls: TLS_accept: Error in error (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed (69) eap_tls: ERROR: System call (I/O) error (-1) (69) eap_tls: ERROR: TLS receive handshake failed during operation (69) eap_tls: ERROR: [eaptls process] = fail </DEBUG> openssl -verify have no warning, if I do cert check manually. Fo testing, I append the certs. # openssl verify -verbose -CAfile /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem SEP64A0E714844E-L1.pem # SEP64A0E714844E-L1.pem: OK Regards Robert -----Ursprüngliche Nachricht----- Von: Stefan Winter [mailto:stefan.winter@restena.lu] Gesendet: Donnerstag, 21. Dezember 2017 14:52 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>; Boris Lytochkin <lytboris@yandex-team.ru>; Gladewitz, Robert <Robert.Gladewitz@dbfz.de> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate Hi,
It's much better to fix your "CA" cert (which is not). ================ X509v3 Basic Constraints: critical CA:TRUE ================ is missing.
Out of curiosity (I didn't think Cisco can be so stupid to make CAs which aren't actually CAs...) I searched, and my search engine of choice gave me this link: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut82798/?referring_site=bug... (needs free registration to view) So, indeed, Cisco WAS that stupid. For an extended amount of time and multiple major version releases. FWIW, if the OP can upgrade his system to release 11.5 and re-generate the CAPF CA, then he should get a real CA. Which then makes tinkering with source code obsolete. (If the answer is that you need to edit the source code, then you are asking the wrong question :-) ) Greetings, Stefan Winter Am 20.12.2017 um 07:51 schrieb Boris Lytochkin:
Hi.
See http://www.alvestrand.no/objectid/2.5.29.19.html
On 20.12.2017 1:09, Gladewitz, Robert via Freeradius-Users wrote:
Hello Alan,
so, i find out that you are right. I find out, that the certificate check ends with an warning, because of following openssl function in v3_purp.c?
495 /*- 496 * CA checks common to all purposes 497 * return codes: 498 * 0 not a CA 499 * 1 is a CA 500 * 2 basicConstraints absent so "maybe" a CA 501 * 3 basicConstraints absent but self signed V1. 502 * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. 503 */ 504 505 static int check_ca(const X509 *x) 506 { 507 /* keyUsage if present should allow cert signing */ 508 if (ku_reject(x, KU_KEY_CERT_SIGN)) 509 return 0; 510 if (x->ex_flags & EXFLAG_BCONS) { 511 if (x->ex_flags & EXFLAG_CA) 512 return 1; 513 /* If basicConstraints says not a CA then say so */ 514 else 515 return 0; 516 } else { 517 /* we support V1 roots for... uh, I don't really know why. */ 518 if ((x->ex_flags & V1_ROOT) == V1_ROOT) 519 return 3; 520 /* 521 * If key usage present it must have certSign so tolerate it 522 */ 523 else if (x->ex_flags & EXFLAG_KUSAGE) 524 return 4; 525 /* Older certificates could have Netscape-specific CA types */ 526 else if (x->ex_flags & EXFLAG_NSCERT && x->ex_nscert & NS_ANY_CA) 527 return 5; 528 /* can this still be regarded a CA certificate? I doubt it */ 529 return 0; 530 } 531 }
But it is documented as a warning, not an error!?
It is possible, to add an workarround for mistake in conf / tls.c
<DIFF tls.c> if (!my_ok && (conf->allow_expired_crl) && (err == X509_V_ERR_CRL_HAS_EXPIRED)) { my_ok = 1; X509_STORE_CTX_set_error( ctx, 0 ); }
+ if (!my_ok && + (conf->allow_wrong_purposed) && + (err == X509_V_ERR_INVALID_PURPOSE)) { + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + }
if (!my_ok) {
</DIFF>
I hope, my mail not sounds arogant :-(
Robert
-----Ursprüngliche Nachricht----- Von: Freeradius-Users [mailto:freeradius-users-bounces+robert.gladewitz=dbfz.de@lists.freer adius.org] Im Auftrag von Alan DeKok Gesendet: Dienstag, 19. Dezember 2017 18:49 An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate
On Dec 19, 2017, at 12:18 PM, Boris Lytochkin <lytboris@yandex-team.ru> wrote: Alan, you are absolutely correct about OIDs. But one thing drives me crazy. Robert sent me a full capture (attached) and it is really weird if you compare it to FreeRADIUS logs. ... I have no idea why FreeRADIUS peeks issuer's cert instead of real client's one. I guess something is broken in server's configuration... EAP-TLS sends over the entire certificate chain. OpenSSL walks down the certificate chain, verifying each cert in sequence.
If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert.
When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial"
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi. On 19.12.2017 20:48, Alan DeKok wrote: > If it can't verify the CA or server cert, OpenSSL fails, and we never get to check the client cert. > > When the client cert gets printed, the fields get printed as "TLS-Client-Cert-Serial", not as "TLS-Cert-Serial" Hmm. There is no TLS-Client-Cert-Serial in the debug log indeed. So you're saying that 1) FR gets client cert from the client (not a full chain in our case, see capture) 2) FR tries to check full cert chain and OpenSSL finds the issuer of that client cert has wrong OIDs and raise an error flag. Right? -- Boris Lytochkin Yandex NOC +7 (495) 739 70 00 ext. 7671
participants (4)
-
Alan DeKok -
Boris Lytochkin -
Gladewitz, Robert -
Stefan Winter