Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check

2018-05-25 Thread Jan Tomasek

Hi,

On 02/21/2018 12:42 PM, Tuure Vartiainen wrote:

how to configure this? My problem is that I need to initiate RadSec connection 
by IP adress this way:


Identifiervsup_cz

   Host195.113.xx.x
   Secret  radsec

When I use HOST = IPaddress I've no option how to tell Radiator which value 
compare against SubjectAltName:DNS.


SuljectAltName:DNS matches against configured Host, so it only works when using 
FQDNs.

I changed the feature request to target adding TLS_SubjectAltNameDNS 
configuration option similar to
TLS_SubjectAltNameURI.

http://www.open.com.au/radiator/ref/TLS_SubjectAltNameURI.html#TLS_SubjectAltNameURI


there’s now a new config option TLS_SubjectAltNameDNS in latest patches,
which can be used to define expected FQDN for SubjectAltName:DNS.


thanks for implementing new config option. I finally upgraded a week ago 
and it works perfectly. Exactly as I needed.


Thank you
--
---
Jan Tomasek aka Semik
http://www.tomasek.cz/
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check

2017-10-31 Thread Jan Tomasek

Hi Tuure,

On 10/13/2017 06:57 PM, Tuure Vartiainen wrote:

On 11 Oct 2017, at 20.28, Jan Tomasek  wrote:

Originally we were using hostnames, but as our eduroam federation
was growing Radiator start was going to be slower and slower. Delay
was indeterministic and was caused by hostname to IP translation,
so we switched to IP addresses.  But IP addresses are complicating
peer verification. At this moment we are using TLS_ExpectedPeerName
but our peers sometimes try to use a certificate which has no right
SubjectDN, it would be better to be able to verify
SubjectAltName:DNS. Is there any chance to get this implemented?
Something like TLS_SubjectAltNameURI but for DNS?



Radiator currently supports SubjectAltName:DNS when it’s an initiator
for RadSec connection.


how to configure this? My problem is that I need to initiate RadSec 
connection by IP adress this way:



  Identifiervsup_cz
  
Host195.113.xx.x
Secret  radsec

When I use HOST = IPaddress I've no option how to tell Radiator which 
value compare against SubjectAltName:DNS.


Thanks
--
---
Jan Tomasek aka Semik
http://www.tomasek.cz/
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator

[RADIATOR] Request for TLS_SubjectAltNameDNS check

2017-10-11 Thread Jan Tomasek

Hello,

I'm working as NREN eduroam operator at CESNET. We have connected about 
150 RADSEC peers using a config like this:



  Identifiervsup_cz
  
#Hostradius.vsup.cz
Host195.113.xx.x
Secret  radsec

LocalAddress195.113.xxx.xx

TLS_Protocols   TLSv1, TLSv1.1, TLSv1.2
TLS_CAPath  /etc/ssl/certs
TLS_CertificateFile /etc/ssl/certs/radius1.eduroam.cz.crt
TLS_CertificateType PEM
TLS_PrivateKeyFile  /etc/ssl/private/radius1.eduroam.cz.key
TLS_CRLCheck
TLS_CRLFile /etc/ssl/crl/*.r0
TLS_ExpectedPeerName CN=(|.+/)radius.vsup.cz(|/emailAddress=.+)$

  
  AuthLog   FTICKS
  AuthLog   FTICKS-FULL
  AuthLog   defaultAuthLog


Originally we were using hostnames, but as our eduroam federation was 
growing Radiator start was going to be slower and slower. Delay was 
indeterministic and was caused by hostname to IP translation, so we 
switched to IP addresses.  But IP addresses are complicating peer 
verification. At this moment we are using TLS_ExpectedPeerName but our 
peers sometimes try to use a certificate which has no right SubjectDN, 
it would be better to be able to verify SubjectAltName:DNS. Is there any 
chance to get this implemented? Something like TLS_SubjectAltNameURI but 
for DNS?


Thanks

--
---
Jan Tomasek aka Semik
http://www.tomasek.cz/

___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator