Security

Reply
MVP
Posts: 727
Registered: ‎03-25-2009

Handling certificate expiration

Imagine a network (eap-peap) with user + machine authentication.
Now imagine users with non-ad devices being pushed to an onboarding portal.
After onboarding those devices are allowed back onto the same SSID using eap-tls but in a different vlan with a different role.

Those certificates handed out by clearpass onboard only have a few months validity.


What happens when those certificates expire? Is there any way to make this transition easy for the users seeing how their eap-peap settings have been replaced with eap-tls settings?
When the certificate expires.. is it deleted from the CA or is it just revoked? Can the user immediately request a new certificate?
Can we warn the user in advance and have them easily replace their soon to be expired certificate?

How do other people handle this?

Koen (ACMX #351 | ACDX #547 | ACCP)

-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
Aruba
Posts: 113
Registered: ‎11-21-2011

Re: Handling certificate expiration

> What happens when those certificates expire? Is there any way to make this transition easy for the users seeing how their eap-peap settings have been replaced with eap-tls settings?

 

In ClearPass 6.2, a new TLS client certificate will be generated for devices that enroll when their previous certificate has less than 25% of its lifetime remaining.

 

So, to avoid any disruption for the users, if they have a 4 month certificate they can re-enroll any time in the last month to get a new certificate installed on their device.

 

If the user does not do this, they will not be able to get onto the TLS network (certificate will have expired and the auth will fail).  They can still re-enroll using the existing method (PEAP credentials), which will provision a new certificate.

 

> When the certificate expires.. is it deleted from the CA or is it just revoked? Can the user immediately request a new certificate?

 

Expired is a status independent of "deleted" or "revoked".  Providing the authorization rules allow it, a user can request a replacement certificate if their old certificate has expired.


> Can we warn the user in advance and have them easily replace their soon to be expired certificate?

 

There is an RFE already open for this.  I don't know when this feature will be available, but if you have suggestions on how this should work then please share them and it will get taken into consideration.

 

MVP
Posts: 727
Registered: ‎03-25-2009

Re: Handling certificate expiration

Thanks Amigodave.

 

Problem with this for me is that most of the users will not think to wipe out the tls network settings and reconfigure the peap ones. Especialy on iphones where they can not even 'forget this network' since the config is included in a profile. It took me a minute to figure out how I could delete the network and I'm supposed to be the professional.

 

 

As to renewing the certificate in those last 25%..

Could we not use the expiration date on the certificate to throw up captive portals at selectable intervals?

I see in the role mappings already a condition that sounds usefull: Certificate - not-valid-after.

Can I do some simple calculus in the value field there?  ie. IF(now > ("Certificate - not-valid-after" - 3 weeks)) THEN force captive portal

Currently the value field won't let me do this, it seems to expect a datetime and nothing else. Any way around this?

 

Koen (ACMX #351 | ACDX #547 | ACCP)

-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
MVP
Posts: 727
Registered: ‎03-25-2009

Re: Handling certificate expiration

Anyone? 

Bit despirate here. Surely this is possible to work around?

How about setting a field with a timedate on creating the certificate which we could verify? Is there any field we can do some arithmatic with a date and then use to compare later on during authentication?

Koen (ACMX #351 | ACDX #547 | ACCP)

-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
Aruba
Posts: 1,537
Registered: ‎06-12-2012

Re: Handling certificate expiration

ThiswasbroughtupwithafewmeetingsIhadthisweekandsomeofusaretesting differentoptions tomakeaworkarounduntilitcanbebuiltintothesystem.

 

Unfortunately I have been traveling this week and haven't had the time to test in my lab.

 

I will post more info tomorrow when I can get back to my lab and start testing.

Thank You,
Troy

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.

--Problem Solved? Click "Accepted Solution" in a post.
MVP
Posts: 727
Registered: ‎03-25-2009

Re: Handling certificate expiration

[ Edited ]

Thanks for putting in the extra effort tarnold.. very much apreciated.

Koen (ACMX #351 | ACDX #547 | ACCP)

-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
Aruba
Posts: 113
Registered: ‎11-21-2011

Re: Handling certificate expiration

> I see in the role mappings already a condition that sounds usefull: Certificate - not-valid-after.

> Can I do some simple calculus in the value field there?  ie. IF(now > ("Certificate - not-valid-after" - 3 weeks)) THEN force captive portal

> Currently the value field won't let me do this, it seems to expect a datetime and nothing else. Any way around this?

 

There isn't currently a way to perform this kind of calculation in the rule editor.

 

However, you could use a CPPM Authorization Source to achieve a similar result.  Observe that your IF expression is also equivalent to:

 

IF (now + 3 weeks > Certificate:not-valid-after)

 

So the question then becomes, how to determine the date/time of "now + 3 weeks"?

 

The answer is that you can do this with SQL.  Try the following steps:

 

1. Create a new Authentication Source:

  • Enter the name Time Calculator
  • Select type Generic SQL DB
  • Set the Cache Timeout to 0

2. On the Primary tab:

  • Enter the server name localhost
  • Enter the database name tipsdb
  • Enter the login username appexternal
  • Enter your cluster password as the login password (this is your admin password if you didn't change the cluster password separately)
  • Leave other options as defaults

3. On the Attributes tab:

  • Add a new filter
  • Enter the filter name Three Weeks From Now
  • Enter the query expression as follows

select current_timestamp + interval '3 weeks' as then;

 

  • Create an attribute named then, with an alias name of Three Weeks From Now, set its data type to Date-Time, and enable it as an Attribute

4. Save the authentication source.

5. Enable this as an authorization source in your service(s) of interest.

 

Now, when you create an enforcement policy, you can specify a rule that says:

 

If (Authorization:Time Calculator:Three Weeks From Now  GREATER_THAN  %{Certificate:Not-Valid-After}) ...

 

and this should pretty much achieve what you are trying to do.

 

Even better, you can create whatever time expressions you need using the relatively straightforward SQL syntax, and give them meaningful names in the authorization source ("Three Weeks From Now" in the example above).

 

See these links for more on the SQL syntax you need:

 

For convenience, I've exported the Time Calculator authentication source and attached it to this post; the secret key is eTIPS123.  Note that after importing you'll need to edit it and set the cluster password.

 

MVP
Posts: 727
Registered: ‎03-25-2009

Re: Handling certificate expiration

This seems to work:

Authorization Attributes
Authorization:Time Calculator:3 weeks from now2013-09-23 17:09:40.27299700

 

Altough I haven't been able to fully test it because of the following:

 

Computed Attributes
Certificate:Not-Valid-After1970-01-01 01:00:32

 

I've got a ticket open with TAC to figure out why the "Certificate:Not-Valid-After" is always giving the 1970 date (exact same date and time each authentication) instead of giving the proper "Valid To" date from the client certificate itself (2013-09-03 15:02:09+00).

 

On top of that.. even though 

(Authorization:Time Calculator:3 weeks from now  GREATER_THAN  %{Certificate:Not-Valid-After})

should certainly be valid for the dates above (2013 > 1970) , I still don't get the correct role applied.

 

So, altough it looks very promising, I haven't been able to check this of as working yet.

I'll keep you guys updated.

Koen (ACMX #351 | ACDX #547 | ACCP)

-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
Aruba
Posts: 113
Registered: ‎11-21-2011

Re: Handling certificate expiration

Yes, I ran into the same problem when trying it out in the lab.  We're looking into it further.

 

Note that you can use:

 

select localtimestamp(0) + interval '3 weeks' as then;

 

to get the format closer to what Policy Manager is expecting (YYYY-MM-DD hh:mm:ss).   This doesn't solve the issue with the Certificate:Not-Valid-After, though.

 

MVP
Posts: 727
Registered: ‎03-25-2009

Re: Handling certificate expiration

With localtimestamp(0) in the query is now does seem to work indeed. Except for the linux date offcourse.

 

At least I can now prove to my customer it will work when you guys fix an obvious bug.. That's probably somewhat comforting. :smileywink:

Koen (ACMX #351 | ACDX #547 | ACCP)

-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
Search Airheads
Showing results for 
Search instead for 
Did you mean: