Walk through for External CA usage
Does anyone have a walk through for how to use external certs instead of the internal certification? The internet is full of copy-paste from the documents on how to use the internal cert authority. Sam Fakhreddine Site Systems Administrator Ledcor Industries Inc., Information Services 7008 Roper Road NW, Edmnoton, AB T6B 3H2 p 780-395-5455 | c 780-996-0763 www.ledcor.com<http://www.ledcor.com> FORWARD. TOGETHER.
Sam Fakhreddine wrote:
Does anyone have a walk through for how to use external certs instead of the internal certification?
I'm not sure what that means. The certificates are just files. If you have a certificate, you can just put it into raddb/certs/, and tell FreeRADIUS to use it.
The internet is full of copy-paste from the documents on how to use the internal cert authority.
I would separate *creating* the certs from *using* them. The process of creating certs is complicated, but documented: http://deployingradius.com/documents/configuration/certificates.html Using certs is just editing the configuration files, and pointing to the correct files. Alan DeKok.
Am 02.04.2014 01:30, schrieb Alan DeKok:
Sam Fakhreddine wrote:
Does anyone have a walk through for how to use external certs instead of the internal certification?
I'm not sure what that means. The certificates are just files. If you have a certificate, you can just put it into raddb/certs/, and tell FreeRADIUS to use it.
The internet is full of copy-paste from the documents on how to use the internal cert authority.
I would separate *creating* the certs from *using* them.
The process of creating certs is complicated, but documented:
http://deployingradius.com/documents/configuration/certificates.html
Using certs is just editing the configuration files, and pointing to the correct files.
If you follow Alans recommendation to "leave the Validate Server Certificate box (or equivalent) un-checked" you are likely to get to a quick working result. If you plan to do verification on the client side and not just ignore its content you have to send intermediate certificates (the correctly ordered way). https://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg84043.... Alan: I think some of us lurkers including myself got the message on the list... if you want (even) better doc, contribute. -- Mathieu --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com
Mathieu Simon (Lists) wrote:
If you follow Alans recommendation to "leave the Validate Server Certificate box (or equivalent) un-checked" you are likely to get to a quick working result. If you plan to do verification on the client side and not just ignore its content you have to send intermediate certificates (the correctly ordered way).
https://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg84043....
Alan: I think some of us lurkers including myself got the message on the list... if you want (even) better doc, contribute.
Please. The link above is nice, but it would be nicer to dump the text into the Wiki. People can find information there. Not so much on third-party web sites. Alan DeKok.
Hello, I've tried to use rlm_linelog module to log attributes which contain UTF-8, but it doesn't work as I expected. In the output, I've got lots of "\377" (0xFF in octal), which are actually octets part of multi-byte characters. The problem is in function linelog_escape_func from rlm_linelog.c.
From what I understand, this function works with ASCII strings (single-byte characters), but not with UTF-8.
Is this behaviour on purpose, or has logging of UTF-8 strings been overlooked ? In any case, there is a bug at line 179 of rlm_linelog.c (in branch 3.0.x): snprintf(out, outlen, "\\%03o", *in); Should be something like: snprintf(out, outlen, "\\%03o", (unsigned char)*in); Otherwise we get, for example, "\377\377" instead of "\303\250". I'll log the bug on the issue tracker. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
participants (4)
-
Alan DeKok -
Chaigneau, Nicolas -
Mathieu Simon (Lists) -
Sam Fakhreddine