Re: Problem Using GoDaddy Wildcard Certificate
Hi Thomas, Thomas Simmons wrote on 03.03.2013 03:28: The certification path for my cert is: My Cert GoDaddy Secure Certification Authority Go Daddy Class 2 Certification Authority I added my certificate to the beginning of the chain file provided by GoDaddy (used cat to ensure no errors) and pointed certificate_file to this. I then selected the Go Daddy Class 2 Certification Authority under the network profile. When this did not work, I imported the chain file into my Trusted Root CAs and selected GoDaddy Secure Certification Authority in the wifi profile. This also did not work. Lastly, I cleaned up my certificate store, split apart the chain file into separate files, imported GoDaddy Secure Certification Authority into my Trusted Root CAs, selected the same in the wifi profile, and pointed certificate_file to my cert ONLY. Does anyone see a reason this should not work? newer Windows versions do a fair bit of automagic when they have to deal with certificates, ie. o they do /not/ carry /a complete list of all/ Root-CA certificates that the system will eventually trust, instead they automatically download specific pre-trusted Root-CA certificates from some trusted Microsoft update server, once the user - doing a bit of internet browsing - encounters a server certificate that will eventually be validating its trust path to that Root-CA certificate /for the first time/. o they use the AIA (Authority Information Access) extension in the certificates (if present) to automatically download missing intermediate CA certificates from the URLs specified in the said certificates to auto-complete trustpaths. o they use the CDP (CRL distribution point) extension in the certificates (if present) to automatically download CRLs from the URLs specified in the said certificates. o they use the AIA (Authority Information Access) extension in the certificates (if present) to automatically ask an OCSP-responder for an up-to-date status of the said certificates. o they cache/store those downloaded bits of information My guess is that your Windows system run into some hen-egg-problem trying to download these things from the internet while not having a full internet connection. Ideas on what to try next? If you have that same wildcard certificate running on an SSL-web-server, get your Windows system connected to the Internet and browse to the HTTPS address of that web server *with IE*. Since the system has full Internet access it should download and store/cache all bits it is needing to successfully validate your wildcard certificate. You can check the Windows CRL and OCSP cache using C:\ certutil -URLCache CRL C:\ certutil -URLCache OCSP Then disconnect the system and try re-connecting it using the supplicant with eap-tls authentication. The system should hopefully use the validation info it collected when it was online before since it is then encountering the same wildcard certificate as before and accept your RADIUS-server certificate. This would at least proof my theory. I'm not sure if knowing why it is broken will still help you to use your wildcard cert...at least for freshly set-up Windows systems which were never connected to the Internet or which never have seen your wildcard certificate before when connected to the Internet it will be difficult. Just my 2 cents. Best Regards Reimer p.s. You can clear the Windows CRL and OCSP caches using C:\ certutil -URLCache CRL delete C:\ certutil -URLCache OCSP delete -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team) DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-580 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems using EAP-TLS with freeradius version 2
Jeffrey Hutzelman wrote on 04.02.2008 00:43: --On Thursday, January 31, 2008 05:42:50 PM +0100 Reimer Karlsen-Masur, DFN-CERT [EMAIL PROTECTED] wrote: If the Microsoft Smartcard Logon extendedKeyUsage *is part* of your client certificates they might not work with Windows build-in supplicant. This is not surprising, if that is the only EKU in the cert. I was talking about a set of EKUs like MS Smartcard Logon in combination with clientAuth and eg. e-mail protection...even if I did not state that clearly enough. Windows does not like to use EE-certs containing EKUs clientAuth and MS Smartcard Logon for EAP-TLS with its build-in supplicant. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems using EAP-TLS with freeradius version 2
Stefan Puch wrote on 01.02.2008 09:57: @Reimer Karlsen-Masur If the Microsoft Smartcard Logon extendedKeyUsage *is part* of your client certificates you could work around this by disabling the trust setting of valid certificate usage Microsoft Smartcard Logon in the CAs properties in Windows build-in certificate store on the PDA. As the Microsoft Smartcard Logon extendedKeyUsage *is NOT part* of the client certificates there should be no problem. Something different seems to be not correct. Did you get a PDA using Windows Mobile working with EAP-TLS with Windows build-in supplicant and freeradius? I am afraid, we do not have a Win Mob PDA to test things available. Problems with the non-repudiation keyUsage occured with a SymbianOS based PDA. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems using EAP-TLS with freeradius version 2
Stefan Puch wrote on 31.01.2008 17:05: Hello again, ... @Reimer Karlsen-Masur We know of problems with EE certificates in PDAs containing the non-repudiation flag. If the non-repudiation keyUsage *is part* of your client certificates they might not work with some PDAs build-in supplicants. We found this out by try and error... Additionally Windows build-in supplicants don't like EE certificates with the extendedKeyUsage Microsoft Smartcard Logon (1.3.6.1.4.1.311.20.2.2) when doing EAP-TLS. Apparently the latter issue can also be solved by just disabling the valid certificate usage of Microsoft Smartcard Logon in the issuing CAs trusted usages properties on the system. I'm not sure if understand correctly what you want to say to me (I'm stupid :-)) First I've used TinyCA to generate my certificates, now I will try the Makefile provided in the source-code of freeradius. I think the extendedKeyUsage Microsoft Smartcard Logon should not be set in both variants. If the Microsoft Smartcard Logon extendedKeyUsage *is part* of your client certificates they might not work with Windows build-in supplicant. If the Microsoft Smartcard Logon extendedKeyUsage *is not part* of your client certificates this causes less problems with Windows build-in supplicant. Or do you mean that the extendedKeyUsage Microsoft Smartcard Logon must be disabled on the PDA? If the Microsoft Smartcard Logon extendedKeyUsage *is part* of your client certificates you could work around this by disabling the trust setting of valid certificate usage Microsoft Smartcard Logon in the CAs properties in Windows build-in certificate store on the PDA. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems using EAP-TLS with freeradius version 2
Stefan Puch wrote on 30.01.2008 11:13: Hello everyone, I've got some problems with the new version of freeradius, but before I'm going to open a new bugreport or post long debugtraces from radiusd -X I want to ask here if someone else has made similar experiences. I've set up a freeradius server version 1.1.7 in our club to authenticate several Notebooks. This worked fine with Windows XP, Windows Vista and Linux clients using EAP-TLS certificates (many thanks for the good documentation of the OIDs in the TLS certificate). Then some people came with their mobile devices which are running Windows Mobile 2003, Windows Mobile 5 (WM5) or Windows Mobile6 (WM6) and the problems began. We know of problems with EE certificates in PDAs containing the non-repudiation flag. Additionally Windows build-in supplicants don't like EE certificates with the extendedKeyUsage Microsoft Smartcard Logon (1.3.6.1.4.1.311.20.2.2) when doing EAP-TLS. Apparently the latter issue can also be solved by just disabling the valid certificate usage of Microsoft Smartcard Logon in the issuing CAs trusted usages properties on the system. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to enable only EAP-TTLS type and not EAP-TLS?
This is definitely more elegant than my suggestion but I found that many FreeRADIUS admins get confused by the CA_file CA_path options. They think that they need to place the CA chain from *their FreeRADIUS servers SSL certificate* in the file/directory specified in above options. But by doing so they most likely implicitly trust these CAs for client authentication via eap-tls, ie. they enabled EAP-TLS with some set of trusted CAs that were never intended to authenticate client certs for their organisation. Whereas the CA chain of *their FreeRADIUS servers SSL certificate* should be appended to the server certificate file specified with the certificate_file option. So since specifying an empty CA_file does not work (FreeRADIUS does not start) the only way for a really clean minimal config that is not allowing EAP-TLS is to have an empty CA_path directory. Defining the DEFAULT in the users file like below is a good additional step to rule all other EAP-Types out. my 2 cents Alan DeKok wrote on 09.01.2008 10:55: nikitha george wrote: Hi, I want to enable only TTLS authentication and if the client is requesting any other types EAP-TLS or PEAP the authentication should be denied. I am running freeradius-1.1.6, and if try to disable EAP-TLS module the server itself is not starting up. Please let me know if there are any ways to achieve this. Put this at the top of the users file: DEFAULT EAP-Type != EAP-TTLS, Auth-Type := Reject -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to enable only EAP-TTLS type and not EAP-TLS?
Alan DeKok wrote on 10.01.2008 11:26: Reimer Karlsen-Masur, DFN-CERT wrote: This is definitely more elegant than my suggestion but I found that many FreeRADIUS admins get confused by the CA_file CA_path options. They think that they need to place the CA chain from *their FreeRADIUS servers SSL certificate* in the file/directory specified in above options. I've added some comments in eap.cnf raddb/certs/README explaining more about these issues. But by doing so they most likely implicitly trust these CAs for client authentication via eap-tls, ie. they enabled EAP-TLS with some set of trusted CAs that were never intended to authenticate client certs for their organisation. That's the whole purpose of CA_file, to be honest. Agreed, but usually the CAs of the chain of the RADIUS servers SSL certificate are *not* the CAs that one wants to trust for organisational client authentication. Certs for client authN are mainly issued by organisational CAs. Whereas IMO the SSL cert of the RADIUS server should be issued by a CA which has its root CA certificate preinstalled in the standard certificate stores... Very good that you added some explanatory comments to these options. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to enable only EAP-TTLS type and not EAP-TLS?
[EMAIL PROTECTED] wrote on 10.01.2008 14:53: Hi, RADIUS certificates for EAP should ALMOST ALWAYS be self-signed. That means that no one else can successfully convince the users to send them the passwords. seconded/thirded. as UK eduroam support I agree that such a closed-loop system provides a better protection. though more config and deployment pains, certainly ;-) Actually we were talking about server side config. Looking at the supplicant, the user strongly should enter a fully qualified name of the radius server he is expecting his authN is checked against and he strongly should make sure that his supplicant is checking hard that this FQDN matches the CN of the RADIUS server cert. Usually there is some checkbox/option to enable that behavior. If the supplicant is not configured that strictly, at the end of the day it does not matter if you rolled your own self-signed RADIUS server cert or you have a cert with its root CA pre-installed. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to enable only EAP-TTLS type and not EAP-TLS?
Stefan Winter wrote on 10.01.2008 15:51: Hi, If the supplicant is not configured that strictly, at the end of the day it does not matter if you rolled your own self-signed RADIUS server cert or you have a cert with its root CA pre-installed. Actually, It's not quite the same: if the user at least managed to enable to CA checking, then - for a commercial CA, thousands of untrusted hosts match his check - for a self-signed CA, only one server matches - for a dedicated RADIUS Auth CA, only servers within the administrative reach which are trusted to handle user authentications anyway match This *is* a win in security vs. commercial CAs. agreed when you turn off 2/3 of the possible checks, but if he is that unexperienced as many users are, it is easy to trick them into installing/trusting a new rogue CA or self-signed rogue RADIUS server certificate anyway. Don't forget: The user desperately wants his internet connection -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to enable only EAP-TTLS type and not EAP-TLS?
Hi,
nikitha george wrote on 09.01.2008 10:04:
Hi,
I want to enable only TTLS authentication and if the client is
requesting any other types EAP-TLS or PEAP the authentication should be
denied.
within the eap section you must configure the tls and the ttls section.
Delete the peap section.
I am running freeradius-1.1.6, and if try to disable EAP-TLS module the
server itself is not starting up.
Please let me know if there are any ways to achieve this.
Then to disable the eap-tls functionality you must create an *empty*
directory e.g. ${raddbdir}/certs/trustedCAsForRoamingClients/ and then
within the tls section define
CA_path = ${raddbdir}/certs/trustedCAsForRoamingClients/
Also you must remove the definition of the parameter
CA_file =
This way you don't have any accepted CAs in your config that are trusted CAs
for issued client certificates for eap-tls authentication
Make sure though that you put the radius server certificate and its CA chain
including the root CA certificate in PEM format into the file specified with
the
certificate_file
option in the tls section.
HTH
--
Beste Gruesse / Kind Regards
Reimer Karlsen-Masur
DFN-PKI FAQ: https://www.pki.dfn.de/faqpki
15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen
am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
smime.p7s
Description: S/MIME Cryptographic Signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS cant connect ldap+freeradius+novell
Hi. Martin G wrote: Subject of the novell-server-certificate is : O = WIFITREE OU = Organizational CA Well, that looks like the SubjectDN of your Novell CA certificate. You need to put this CA certificate (no the pkcs#12/.p12 or the private key) in PEM format into the file referenced by option tls_cacertfile. And thats no FQDN!? No. (I exported it from the novell as an .der and extracted it to see the subject, maby wrong way to do it? i havent exported the private key with either the .b64 or the .der and that shouldnt matter ?) You do *not* need the private key of your novell CA cert or your novell ldap server cert on your FreeRADIUS server. *output from novell* This looks like a selfsigned root-CA certificate: Subject name: OU=Organizational CA.O=WIFITREE Issuer name: OU=Organizational CA.O=WIFITREE Effective date: den 22 oktober 2005 23:04:08 Expiration date: den 22 oktober 2015 23:04:08 Certificate status: Valid Any idea how to type the FQDN !? :( You need to get a PEM formatted copy of this CA certificate (w/o private key) and put that to the file referenced by option tls_cacertfile. And for ldapsearch put this certificate into /etc/ldap/ldap.conf as TLS_CACERT /etc/ldap/novell-ca-cert.pem -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS cant connect ldap+freeradius+novell
Martin G wrote: Iv found the following on the novellserver (CA-service): Distinguished name: WIFITREE CA.Security Host server: NW1.SYSTEM.WIFI Well this looks like the novell ldap server certifivate. NW1 would be the servername and NW1.SYSTEM.WIFI the FQDN? Yes. I added the info in all kinds of sorts in my hosts-file to the novell-ip on the linux-server but still no progress :( Still: Put 10.10.0.11 nw1.system.wifi into the /etc/hosts file ldapsearch -vvv -h NW1.SYSTEM.WIFI wifi -x -Z -b ou=adm,ou=malmo,o=wifi cn=lotta ldap_initialize( ldap://wifi ) ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate filter: cn=lotta requesting: All userApplication attributes Any good idea!? Does your ldap server do ldaps on e.g. port 636? To get the ldap server certificate and mybe the CA chain validating this certificate you could try # openssl s_client -connect 10.10.0.11:636 -showcerts -debug -msg -state If your ldap server does not do ldaps try # openssl s_client -connect 10.10.0.11:389 -showcerts -debug -msg -state -starttls pop3 or # openssl s_client -connect 10.10.0.11:389 -showcerts -debug -msg -state -starttls smtp I expect this does not work since openssl s_client does not (yet) support starttls option with ldap protocol. But give it a whirl, maybe you get back something useful. Or enable ldaps on port 636 on your ldap server and try the top most openssl command from this mail. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS cant connect ldap+freeradius+novell
Hi. Martin G wrote: Hello! Im new to both this mailinglist and to novell/linux/ldap/freeradius but iv tried my best to install a radius/ldap linuxserver to pass on radius-requests from a Aruba-controller to our novell-server. IPs: Novell 10.10.0.11 Aruba 10.10.0.28 Linux (freeradius+ldap) 10.10.0.132 Iv tried to change tls_mode, port and tls_start on and off a couple of times without any good result and when i go use ldapsearch -vvv -h 10.10.0.11 -x -Z -b ou=adm,ou=malmo,o=wifi cn=lotta i recieve TLS: hostname does not match CN in peer certificate. At least this means that your ldap server understands STARTTLS on the standard ldap port. So in FreeRADIUS ldap config section you should *not* set port and tls_mode options at all. You should set start_tls=yes though. As for the ldap server certificate name mismatch So i have some thoughts about the certificate, but iv exported the selfsigned novell-certificate from the novellserver and verifyed it. But im not sure how to use a client-certificate on the linux. When i use freeradius -XXX -A on the linuxserver and i trie to do a radius-request, the aruba gets a timeout and the linuxserver tells me the following logg: Now for the certificates. Since your ldap server is using a server certificate you must configure FreeRADIUS to trust the issuing CA. Since identity and password are set it seems you do not use SSL client authentication to authenticate the FreeRADIUS server (acting as ldap client) at the ldap server. Hence don't set tls_certfile and tls_keyfile options. Either use tls_cacertfile xor tlc_cacertdir option. If using former, put in all the CA certificate chain validating the ldap servers certificate in PEM format. Concatenate the CA certs into the file named by this option. If using the latter, put all CA certs of the chain validating the ldap servers certificate in PEM format with .pem file extension into that directory. cd into this directory and execute # c_rehash . to build some symlinks. The dot (.) for the current directory seems vital. c_rehash is a tool that comes with openssl. Be aware that the openldap client configuration file on the system or for that user running FreeRADIUS is being used. That is ~/.ldap.conf or system wide something like /etc/openldap/ldap.conf or what ever fits your FS layout and ldap installation on the FreeRADIUS server. To ease ldap debugging within FreeRADIUS set loglevel -1 in the ldap.conf file. Debugging output is to be found in files configured by syslogd more than likely in /var/log/messages or similar. HTH good luck -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS cant connect ldap+freeradius+novell
Hm. Martin G wrote: Sorry, when i tried to rehash my certificate, id changed its path, but now its back and i got a new output from my ldapsearch-command: ldapsearch -vvv -h 10.10.0.11 -x -Z -b ou =adm,ou=malmo,o=wifi cn=lotta ldap_initialize( ldap://10.10.0.11 ) ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate What is the CN in the SubjectDN of the ldap servers certificate? Is it a FQDN? If so, try to map IP# 10.10.0.11 to this FQDN via /etc/hosts if your DNS server can't find the FQDN. Try to call ldapsearch with -h FQDN option. Is above warning going away? filter: cn=lotta requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base ou=adm,ou=malmo,o=wifi with scope subtree # filter: cn=lotta # requesting: ALL # # lotta, ADM, MALMO, WIFI dn: cn=lotta,ou=ADM,ou=MALMO,o=WIFI zenzfdVersion:: Something is at least working. It's not SSL secured though. ... Iv also added the loglevel -1 to the /etc/ldap/ldap.conf and removed the TLSCertificateFile and TLSCertificateKeyFile from the /etc/ldap/sldap.conf as i did forget before. slapd.conf is the config file of the openldap *server*. Messing with this file should not change anything. Or was that a typo? Do i need to convert the certificate to .pem and how if the c_rehash dont work? If tls_cacertdir is not set, then don't use c_rehash. Set tls_cacertfile to a single ASCII file containing all PEM formatted CA certificates of the CA certificate chain that is needed to validate your ldap servers certificate. Concatenate these PEM formatted CA certs into this single ASCII file. And I forgot, set ldap_debug to -1 in the radius config file. Don't send your ldap servers password in log files ;-) ... Tue Jul 10 12:35:00 2007 : Debug: Module: Loaded LDAP Tue Jul 10 12:35:00 2007 : Debug: ldap: server = 10.10.0.11 Tue Jul 10 12:35:00 2007 : Debug: ldap: port = 389 Tue Jul 10 12:35:00 2007 : Debug: ldap: net_timeout = 1 Tue Jul 10 12:35:00 2007 : Debug: ldap: timeout = 4 Tue Jul 10 12:35:00 2007 : Debug: ldap: timelimit = 3 Tue Jul 10 12:35:00 2007 : Debug: ldap: identity = cn=admin,o=wifi Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_mode = no Tue Jul 10 12:35:00 2007 : Debug: ldap: start_tls = yes Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_cacertfile = /etc/freeradius/certs /WIFITREE_CA.b64 Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_cacertdir = (null) Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_certfile = (null) Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_keyfile = (null) Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_randfile = (null) Tue Jul 10 12:35:00 2007 : Debug: ldap: tls_require_cert = allow Tue Jul 10 12:35:00 2007 : Debug: ldap: password = novell Tue Jul 10 12:35:00 2007 : Debug: ldap: basedn = ou=adm,ou=malmo,o=wifi ... Tue Jul 10 12:35:00 2007 : Debug: ldap: ldap_debug = 0 Tue Jul 10 12:35:00 2007 : Debug: ldap: ldap_connections_number = 5 Tue Jul 10 12:35:00 2007 : Debug: ldap: compare_check_items = no -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: certificates for TLS Tunnel (peap mschap v2 authentication)
Hi, julien blanc wrote: hi ! I'd like to set up an authentication system (for wireless clients) based on freeradius. I'm using a DC windows 2003 with Active Directory to manage my users and groups... i know ... its bd :-) but i don't have the choice ! I have built a linux server (fedora core 5), with freeradius, a kerberos client, samba and winbind to reach my domain. No problems so far. I'd like to authenticate my supplicants with PEAP-MSCHAP v2 and so i must set up a PKI for the TLS tunnel. well, you need a server certificate for your FreeRADIUS server. My problem is here. I don't know how to use certificates in the freeradius directory: This is some root-CA certificate and its secrete key: root.pem, root.p12, root.der This is a client cert signed by above root-CA certificate and its secrete key (you only need this when doing EAP-TLS): cert-clt.pem, cert-clt.p12, cert-clt.der This is a server cert signed by above root-CA certificate and its secrete key (you can use this cert as server certificate of FreeRADIUS): cert-srv.pem, cert-srv.p12, cert-srv.der The slides on http://www.dfn.de/content/fileadmin/1Dienstleistungen/Roaming/DFNRoaming-Workshop-20070426-Handout.pdf page 20ff might help. Googles language tools might be some help :-/ any advice ... suggestions or anything else ??? As for the passwords of the .p12 files or secret keys: you set them yourself if you did not leave them empty On the Windows supplicants you can import the root.pem file. *Check* that this file *does not* contain the private key. It's in ASCII format, so you can look into the file and will see, if it's just the cert or if there is an additional key in the file. If the latter is the case make a copy of that file and remove the key part. Rename the file to .cer or .crt and import the result into Windows supplicants by double clicking or MMCs certificate snap-in. Client certificates are *not* needed for PEAP ms-chapv2. HTH -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending CA certificate during EAP-TLS
Hi.
Eshun Benjamin wrote:
Well in my current configuration I have the RADIUS server certificate in
certificate_file and CA certificate in CA_file.
But with that configuration , the radius server is still sending the CA
certificate.
The CA_path folder is empty and the CA_file is commented out. This
should work for you.
tls {
#
# These is used to simplify later configurations.
#
certdir = ${raddbdir}/certs
cadir = ${raddbdir}/certs/trustedCA
private_key_password = whatever
private_key_file = ${certdir}/server.pem
certificate_file = ${certdir}/server.pem
# Trusted Root CA list - CA_path folder is empty
# CA_file = ${cadir}/ca.pem
CA_path = ${raddbdir}/certs/trustedCA
If the configuration is as minimal as suggested (no chain certificates in
certificate_file) and FreeRadius is still sending the complete server CA
chain build, this must be some FreeRadius magic
How do you check if FreeRadius is actually sending the chain?
--
Beste Gruesse / Kind Regards
Reimer Karlsen-Masur
DFN-PKI FAQ: https://www.pki.dfn.de/faqpki
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
smime.p7s
Description: S/MIME Cryptographic Signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending CA certificate during EAP-TLS
Hi, Rafa Marín López wrote: Reimer Karlsen-Masur, DFN-CERT escribió: Hi Karlsen, thanks for the answer, please see inline... Argh, your misunderstanding is because of the inline documentation/default setup of the eap config file. *Trusted* CAs for client auth are stored in CA_file or CA_path So there is no conflict here with certificate_file option. And IMO usually CA_file and certificate_file should *not* contain the same CA certs Well in my current configuration I have the RADIUS server certificate in certificate_file and CA certificate in CA_file. But with that configuration , the radius server is still sending the CA certificate. Having said that , your proposal was to not include the CA certificate in the RADIUS server certificate (in certificate_file variable) My RADIUS server certificate does not have the CA certificate included. Even so, the RADIUS server is including the CA certificate :(... any alternative solution?. No. If the configuration is as minimal as suggested (no chain certificates in certificate_file) and FreeRadius is still sending the complete server CA chain build, this must be some FreeRadius magic How do you check if FreeRadius is actually sending the chain? -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending CA certificate during EAP-TLS
Hi, in the file referenced by the option variable certificate_file in the tls section only put the server certificate (and optionally the private key) of your RADIUS server. i.e. don't put ca certificates of the chain into that file. I don't know how to prevent the client from sending CA path certificates Rafa Marin wrote: Hi all, Is there any way to configure free radius + eap-tls module to avoid to send CA certificate during EAP-TLS negotiation? As Free Radius is sending it right now EAP-TLS packets get fragmented and I would like to avoid it. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending CA certificate during EAP-TLS
Rafa Marin wrote: Hi Karlsen, 2007/6/20, Reimer Karlsen-Masur, DFN-CERT [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi, in the file referenced by the option variable certificate_file in the tls section only put the server certificate (and optionally the private key) of your RADIUS server. I think this might work (after some tests i did). But my immediate question is how the server is supposed to verify client certificate if we don't configure any CA certificate?. Argh, your misunderstanding is because of the inline documentation/default setup of the eap config file. *Trusted* CAs for client auth are stored in CA_file or CA_path So there is no conflict here with certificate_file option. And IMO usually CA_file and certificate_file should *not* contain the same CA certs because I guess in the majority of cases the RADIUS server cert is issued by some (commercial) server CA where as the client certs are mostly issued by some home grown user CA. Saying that there might be cases where the CA certificates from CA_file are indeed the CA chain certs of the RADIUS server certificate. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Disabling EAP-TLS while keeping EAP-PEAP
Hi, it's very similar to pages 20ff of http://www.dfn.de/content/fileadmin/1Dienstleistungen/Roaming/DFNRoaming-Workshop-20070426-Handout.pdf Eshun Benjamin wrote: sounds interesting can you post your tls section config -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Disabling EAP-TLS while keeping EAP-PEAP
Hi!
By commenting the CA_file parameter in the eap-tls section:
# CA_file = ${raddbdir}/certs/trusted-ca-cert-list.pem
*and*
by setting CA_path parameter in the eap-tls section to an *empty* directory
CA_path = ${raddbdir}/certs/trustedCAs
should do the trick.
No trusted CAs mean no trusted client certificates :-)
Martin Gadbois wrote:
When enabling EAP-PEAP with FreeRADIUS, module EAP-TLS is required.
How can I disable EAP-TLS while using EAP-PEAP?
I agree that if the client does not have a client key, EAP-TLS will not
work. But how to restrict EAP-TLS in any case?
--
Beste Gruesse / Kind Regards
Reimer Karlsen-Masur
DFN-PKI FAQ: https://www.pki.dfn.de/faqpki
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
smime.p7s
Description: S/MIME Cryptographic Signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: signed certificate
Hi, do you mean a RADIUS *Server* certificate? Show us the openssl x509 -noout -text -in your-cert.pem output of your certificate that is currently not working and we can make a guess why it might not working. From the vendor website I can't workout which keyusage extensions and/or Netscape certificate types are set in your certificate. Phil Brown wrote: Can any one recommend a signed certificate provider whose certificates work with the Microsoft 802.1x client. I currently have a system that works fine with a self signed certificate but fails to work with a Digicert signed certificate, so we are looking to purchase a certificate that will work. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Wildcard RADIUS-server certificate and rarely used subjectRDN OIDs under 2.5.4.x arc working with Windows PEAP/EAP-TLS? (Was: Re: signed certificate)
Got the requested openssl output via pm. PKIX extendedKeyUsage is set OK. Additionally Netscape Cert Type is set accordingly to EKU. But: It is a wildcard certificate. And the SubjectDN contained among commonly used RDNs (like C, ST, L, O, OU and CN) a view RDNs that are rarely used in certificates like OIDs 2.5.4.17, 2.5.4.9 and 2.5.4.9 which are X.500 attributs (http://www.faqs.org/rfcs/rfc2256.html, http://www.alvestrand.no/objectid/2.5.4.html). I have not a clue if Windows built-in EAP-TLS or PEAP supplicant has problems with these. Anyway, these oddities raised my suspicion. Can anybody confirm that RADIUS-Server certs with these rarely used OIDs in the sDN and/or a wildcard CN is working with Windows build-in PEAP/EAP-TLS? Alan DeKok wrote: Phil Brown wrote: Can any one recommend a signed certificate provider whose certificates work with the Microsoft 802.1x client. I currently have a system that works fine with a self signed certificate but fails to work with a Digicert signed certificate, so we are looking to purchase a certificate that will work. OpenSSL creates usable certificates. I would suggest calling Digicert, and telling them the certificate you paid for is useless. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap-tls authentication with free radius 1.1.5
Hi Anoop, could you *please* fix your quoting! Maybe http://www.dfn.de/content/dienstleistungen/dfnroaming/workshops/wsarchiv/ (handout Server(Freeadius)-/Client Zertifizierung durch die DFN-PCA - Wie geht das? Was ist zu beachten? are in German language but the FreeRADIUS config part is obviously reusable. Beware that this handout will be slightly updated shortly because I sent an updated version to the maintainer of this website) or http://www.geant2.net/upload/pdf/GN2-06-258v8-DJ5-1-5_Inter-NREN_Roaming_Infrastructure_and_Service_Support__Cookbook_1st_Version.pdf are of interest for you. [EMAIL PROTECTED] wrote: Hi Alan I stil havn\'t get the exact problem.Earlier i was using freeradius-snapshot-20021028 .For eap-tls i made changes in radiusd.conf,clients.conf and users file. With 1.1.5 version i didn;t change radiusd.conf. Pls tell me what are the configuration required in the radiusd.conf,eap.conf,clients.conf and users file. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS PEAP MCHAPv2
Hey. Append all intermediate CA certificates onto the end of the file specified with the certificate_file option in the eap.conf files eap-tls section. This file usually hold your RADIUS server certificate and can additionally hold the chain certificates as well. Eshun Benjamin wrote: I am using an enterprise certificate which has intermediate CA. The root CA is well known (verisign) and already on the MAC keychain access(3.3) by default. MAC recognises the certificate and its validity but complains of The server certificate is not trusted because there are no explicit trust settings. If I click continue or always trust it works fine but I want to get rid of this prompt without clicking continue or always trust to give it smooth and uninteractive log on. -- Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Win XP with 802.1x PEAP (EAP-MSCHAP V2)
Hi Marc, are you aware of PEAP authentication is not successful when you connect to a third-party RADIUS server http://support.microsoft.com/kb/885453 Maybe it is somehow related? Other updates I installed on XP SP2 for WLAN 802.1x and PEAP/EAP-TLS are Hotfix 917021 (Wireless Client Update) http://support.microsoft.com/kb/917021 Hotfix 893357 (WPA2 Update) http://support.microsoft.com/kb/893357 Marc Charbonneau wrote: Ok, I minted the Certificates/Keys with a CA running on a Windows 2003 server and was able to get them into the PEM format. The EAP.CONF was modified accordingly and RADIUSD is happy. I am still able to authenticate with no problems with 802.1x PEAP (EAP-MSCHAP V2) when using Cisco's ADU configuration tool. Still have problems when using the Windows XP supplicant. In trying to authenticate with the Windows XP supplicant, I can see from the logs that it's changing the password's 1st character to an a. If you look at the log data below, you'll see that the user account UOHI-40615 being used to authenticate is failing because the password sent is aassword2 instead of password2. Are you typing your username/password on demand or has XP earlier stored it magically and is reusing this? If the latter, have you once typed the wrong password and XP is remembering the wrong password? Does anyone know how to fix this problem? I'm so close, please help me find the needle in the haystack. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Win XP with 802.1x PEAP (EAP-MSCHAP V2)
Hi. [EMAIL PROTECTED] wrote: either use your current tool but include the XP extensions as required, Just to be precise. The named extensions are PKIX extensions for serverAuth (OID 1.3.6.1.5.5.7.3.1) (at the RADIUS server) and clientAuth (OID 1.3.6.1.5.5.7.3.2) (for EAP-TLS on the supplicant). Also if a client certificate is used on Windows with EAP-TLS the extendedKeyUsage Microsoft SmartCard Logon (OID 1.3.6.1.4.1.311.20.2.2) *must not* be present because Windows won't be able to use/choose such a client certificate to authenticate at the RADIUS server. It is only Windows that is looking at these extededKeyUsages in the certificate and expecting the correct extensions here. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TLS: getting updated CRLs via cron for use with check_crl = yes option for EAP-TLS client-authN
Hi, here is a pointer to a useful script I use to fetch updated CRLs for client-certificate issuing CAs from their http CDPs via cron. http://dist.eugridpma.info/distribution/util/fetch-crl/ Just add a restart for the radiusd to make it aware of new CRLs. -- Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Questions regarding authentication systems and protocols to password types compatibility
Hi Alan, hi list, I appreciate the tables explaining the compatibility of authentication systems / protocols to password type compatibility from: [table 1] http://deployingradius.com/documents/protocols/compatibility.html and [table 2] http://deployingradius.com/documents/protocols/oracles.html But I am still confused about the relationship of these two tables to each other and how to use them. Is the following considered correct? 1. If I am using the back end DB (e.g. ldap or users file, etc.) as a simple *password store*, only [table 1] if of interest. And freeradius is able to connect to the back end (if there is a rlm_back-end-db module available), authenticate itself with a special radius server account/user credential and to retrieve the password plus optionally some other attribute values if the radius server *itself* authenticates successfully with the back end DB. The radius server itself is then performing the user name/password check to accept or reject the authentication request of the user trying to connect. 2. If I am using the back end DB (e.g. ldap etc.) as an *authentication oracle*, [table 2] tells me which authentication oracle system I can use (depending on the authentication protocol that the supplicant/client/user is using) and [table 1] tells me in which format the passwords need to be stored in the authentication oracle. And freeradius is able to connect to the back end (if there is a rlm_back-end-db module available), to authenticate *with the user provided* credentials (username/password) and to optionally retrieve some attribute values if the *user* authenticated successfully against the authN oracle. Confirmation or further clarification is welcome. Thanks Reimer ps: There is probably a small typo in the column heading of [table 1]: 'SSHA1 hash' should be 'SHA1 hash' and 'Salted SSHA1 hash' should be 'Salted SHA1 hash (SSHA1)' -- Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Questions regarding authentication systems and protocols to password types compatibility
Thanks Alan! Your answer is raising some more questions though: Alan DeKok wrote: Reimer Karlsen-Masur, DFN-CERT wrote: I appreciate the tables explaining the compatibility of authentication systems / protocols to password type compatibility from: But I am still confused about the relationship of these two tables to each other and how to use them. Is the following considered correct? 1. If I am using the back end DB (e.g. ldap or users file, etc.) as a simple *password store*, only [table 1] if of interest. Yes. Which freeradius modules can be used for the *simple password store*? files (the users file) unix pam ldap sql (?) Could you please complete this list? Are these entries ending up in the authenticate or authorize or both sections of the freeradius config? ... 2. If I am using the back end DB (e.g. ldap etc.) as an *authentication oracle*, [table 2] tells me which authentication oracle system I can use (depending on the authentication protocol that the supplicant/client/user is using) Yes. and [table 1] tells me in which format the passwords need to be stored in the authentication oracle. Yes. Except that PAP is compatible with all password formats. Also, ntlm_auth is used on Windows, which stores passwords in cleartext or NT-Hash format, and nothing else. So after reading the oracle page, there's no need to go back to the other page to see how to store the passwords. And freeradius is able to connect to the back end (if there is a rlm_back-end-db module available), to authenticate *with the user provided* credentials (username/password) and to optionally retrieve some attribute values if the *user* authenticated successfully against the authN oracle. No. Authentication has nothing to do with retrieving other information. When an authentication oracle is used, FreeRADIUS takes the username password, and hands them to the oracle. The oracle returns yes/no, and nothing else. How do I differ within the ldap module configuration if I do an ldap authentication via the *oracle* or if I *retrieve* (additional) attributes for a user like e.g. his password? Is the difference that the 'ldap' entry shows up in the 'authenticate' section for attribute retrieval use (plain password store) which I have configured here and believe to be working and in the 'authorize' section for oracle use? Thanks again for more insight on this! -- Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: problem with freeradius fedors core 5,6
Hi. Look (http://www.mail-archive.com/freeradius-users@lists.freeradius.org/ at emails/threads to this list with the Subject: freeradius-1.1.5 : Aborted(core dump) and freeradius + branch_1_1 via cvs ? CVS branch_1_1 is your bet. Fixed it here, too. @ Alan: Are you releasing version 1.1.6 fixing this issue? Jackson Jerry-NPC637 wrote: ... *** glibc detected *** radiusd: double free or corruption (fasttop): 0x08b30140 *** -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CA Chain
Jeffrey Sewell wrote: Thank you for your reply. We are (with the exception of some prototype tests) going to be completely EAP-TLS. Your answer brings me back to my original issue--the CA_path does not exist in the eap.conf file. If I add it, it doesn't seem to work (on 1.1.4). Hm, here it does work. Have you run c_rehash in that directory? Are the files and the directory readable by the radiusd process? Did you choose to run radiusd under some other user than root? Just adding additional certs to the CA_file seems to work, but I'd prefer to have proper signed (c_reshash) sym-links. ??? This is not a signature, its some very short fingerprint of the SubjectDN of the CA cert. Have you set verify_depth = 0 for a start? You should set it probably to the lowest positive integer (except 0) that your CA hierachie setup and your client certs are working with. Have you set check_crl = no to test if the CA certificate setup is working. Later on you should set it to yes for obvious reasons and get uptodate CRLs. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), DFN-CERT Services GmbH DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 14. DFN-CERT Workshop und Tutorien, CCH Hamburg, 7.-8. Februar 2007 Infos/Anmeldung unter: https://www.dfn-cert.de/events/ws/2007/ smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CA Chain
Jeffrey Sewell wrote:
Than you.
So if I understand this correctly, radiusd is not looking for a
directory with checksum'd certificates, just one file with all the
certficates in it?
Both is possible.
CA_path = ${raddbdir}/certs/trustedCAs/
with c_rehash generated fingerprint symlinks for a directory of trusted CA
certificates for EAP-TLS (with client authentication by client certificates).
Or
CA_file = ${raddbdir}/certs/trustedCAs.pem
a file with possibly multiple PEM formatted CA certificates for EAP-TLS
(with client authentication by client certificates).
My point was that the chain of the radius-server-certificate is actually to
be *added* to the file with the radius-server-certificate itself.
And that if you want to do plain EAP- *T* TLS and only EAP-TTLS to be
carefull to leave CA_file and CA_path nulled/empty.
I remember that the inline documentation of the eap.conf file suggests to
put the CA certificate issuing the radius-servers server-certificate into
the CA_file which could open up unwanted EAP-TLS client authentication by
client certificates if this CA issued client certificates.
If you configure radiusd to do EAP-TLS also make sure to use the check_crl =
yes option and have up-to-date CRLs available in the CA_path. Make sure
c_rehash is building the fingerprint symlinks here as well.
To automatically freshen/download CRLs by e.g. cron there is a neat script
with some build-in CRL checking etc available at
http://dist.eugridpma.info/distribution/util/fetch-crl/
HTH
--
Kind Regards
Reimer Karlsen-Masur
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), DFN-CERT Services GmbH
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
14. DFN-CERT Workshop und Tutorien, CCH Hamburg, 7.-8. Februar 2007
Infos/Anmeldung unter: https://www.dfn-cert.de/events/ws/2007/
smime.p7s
Description: S/MIME Cryptographic Signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CA Chain
Jeffrey Sewell wrote:
In the eap.conf, tls section, the comments say to use the 'CA_path'
variable in the radiusd.conf file to indicate where the trusted CA
chain will reside. However, this variable isn't in the tls section of
the radiusd.conf file (it is in the LDAP section, but I'm pretty sure that
won't help me) or the eap.conf file (where I thought it might
have moved). As an experiment, I added it to eap.conf and it loaded ok
with the following output:
tls: CA_path = /usr/local/etc/raddb/certs/rootCA
...
tls: CA_file = (null)
Unfortunately the CA_file is the imporant one as I discovered when I
tested the link:
Fri Jan 19 09:51:05 2007 : Error: TLS Alert write:fatal:unknown CA
So where is the appropriate place for the root chain?
for eap-tls and eap-ttls in eap.conf in the eap section and thereof in the
tls section put the server certificate of your radius server into the file
eap {
...
tls {
...
private_key_file = ${raddbdir}/certs/radius-server-key.pem
certificate_file = ${raddbdir}/certs/radius-server-cert-and-chain.pem
...
}
...
}
and then *add* the appropriate chain ca certificates to this file.
Additionally if you do *not* use eap-tls you want CA_path= point to an
existing *empty* directory and you do *not* want to specify the CA_file option.
eap {
...
tls {
...
# CA_file = /dev/null
CA_path = ${raddbdir}/certs/trustedCAs-emptydir/
verify_depth = 1
...
}
...
}
If you were looking to use the radius server as *LDAP client* to a backend
LDAP database above options are not relevant for the LDAP client part. In
this case you need to fiddle with the options in radiusd.conf under modules
and thereof under the ldap section:
modules {
...
ldap {
...
# start_tls = no
# tls_cacertfile =
${raddbdir}/certs/trusted-root-CA-certs-for-ldap-server.pem
# tls_cacertdir =
${raddbdir}/certs/trusted-root-CA-certs-dir-for-ldap-server/
# tls_keyfile = ${raddbdir}/certs/radius-ldap-client-key.pem
# tls_certfile = ${raddbdir}/certs/radius-ldap-client-cert-and-chain.pem
# tls_randfile = ${raddbdir}/certs/rnd
# tls_require_cert = demand
...
}
...
}
HTH
--
Beste Gruesse / Kind Regards
Reimer Karlsen-Masur
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), DFN-CERT Services GmbH
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
14. DFN-CERT Workshop und Tutorien, CCH Hamburg, 7.-8. Februar 2007
Infos/Anmeldung unter: https://www.dfn-cert.de/events/ws/2007/
smime.p7s
Description: S/MIME Cryptographic Signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
