On 03/26/2012 04:14 PM, Alexander Hartmaier wrote:
> I didn't find anything regarding autoloading of the crl in the openssl
> changelog so the patch must still be not mainline.
> We're using Debian Squeeze (6) on the server with openssl from the
> testing tree to get openssl 1.0.0 which is now at
Hi Heikki,
Am 2012-03-22 17:16, schrieb Heikki Vatiainen:
> On 03/21/2012 12:11 PM, Alexander Hartmaier wrote:
>
>> Now that our dot1x and WLAN Radiator needs to check three different crls
>> I've looked into a better solution for refreshing them.
>> While reading Radius::TLS I've stumbled over th
On 03/22/2012 06:16 PM, Heikki Vatiainen wrote:
>> In the contextInit method you've put a note # REVISIT: what if a CRL
>> changes while we are running?
>
> Hmm, that might be a little older comment, I'll check that too.
Yes, that's old and will be removed.
--
Heikki Vatiainen
Radiator: the
On 03/21/2012 12:11 PM, Alexander Hartmaier wrote:
> Now that our dot1x and WLAN Radiator needs to check three different crls
> I've looked into a better solution for refreshing them.
> While reading Radius::TLS I've stumbled over the method reloadCrls which
> claims to reload the crl if the times
Now that our dot1x and WLAN Radiator needs to check three different crls
I've looked into a better solution for refreshing them.
While reading Radius::TLS I've stumbled over the method reloadCrls which
claims to reload the crl if the timestamp changes. Has this ever worked?
In the contextInit metho
On 02/01/2012 03:42 PM, Alexander Hartmaier wrote:
Hello Alexander,
> I've encountered another problem.
> I've written a bash script that downloads the crl once a day at one
> o'clock in the morning local time and restarts radiator afterwards
> because of the openssl crl caching.
> The CRL lifeti
Hi,
I've encountered another problem.
I've written a bash script that downloads the crl once a day at one
o'clock in the morning local time and restarts radiator afterwards
because of the openssl crl caching.
The CRL lifetime ends about 30 minutes later and radiator rejects all
auths after that tim
Am 2011-08-09 10:35, schrieb Heikki Vatiainen:
> On 08/08/2011 05:59 PM, Alexander Hartmaier wrote:
>> So a reload after every crl download is still the only solution?
> Unfortunately this seems to be currently the only solution.
>
>> Adding the crl download and refresh functionality to Radiator wo
Hi Heikki,
actually there is NO way to force a CRL reload except to kill the process.
The certificates are NEVER flushed from the process under any
circumstances :-( You can load new ones but the old ones are looked at before
the recent ones.
Cheers.
On Tuesday 09 August 2011 06:35:20 pm Heikk
On 08/08/2011 05:59 PM, Alexander Hartmaier wrote:
> So a reload after every crl download is still the only solution?
Unfortunately this seems to be currently the only solution.
> Adding the crl download and refresh functionality to Radiator would be a
> welcome addition!
I agree this would be v
So a reload after every crl download is still the only solution?
Adding the crl download and refresh functionality to Radiator would be a
welcome addition!
Cheers, Alex
Am 2011-08-08 09:41, schrieb Heikki Vatiainen:
> On 08/02/2011 01:59 PM, Alexander Hartmaier wrote:
>
> Hello Alexander,
>
>> wh
On 08/02/2011 01:59 PM, Alexander Hartmaier wrote:
Hello Alexander,
> what's the status of crl reloading?
CRL reloading support depends on OpenSSL. As you have found out, it
appears the support is not in version 1.0.0. A quick check of 1.0.0
series change log did not show anything related to thi
Hi guys,
what's the status of crl reloading?
I've installed openssl 1.0.0 from Debian testing on a Debian stable
server but it still fails with
ERR: Failed to add CRL file '/etc/radiator/certificates/foo.crl.pem':
error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already
in hash tabl
13 matches
Mail list logo
