AW: After Upgrade from freeradius 2 to 3 (Debian 8 - 9): TLS Alert write:fatal:unsupported certificate

[Gladewitz, Robert]

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 at restena.lu] 
Gesendet: Donnerstag, 21. Dezember 2017 12:33
An: Gladewitz, Robert <Robert.Gladewitz at dbfz.de>
Cc: freeradius-users at 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 at restena.lu]
> Gesendet: Donnerstag, 21. Dezember 2017 11:08
> An: Gladewitz, Robert <Robert.Gladewitz at dbfz.de>; FreeRadius users 
> mailing list <freeradius-users at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6245 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20171221/dcb7e361/attachment.bin>