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)
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
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
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.
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
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
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
[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
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
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.
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
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
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
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:
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
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
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
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
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
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:
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
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
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
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
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
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)
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).
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
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]
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
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
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
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
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
34 matches
Mail list logo
