Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Handling certificate expiration

This thread has been viewed 13 times
  • 1.  Handling certificate expiration

    MVP
    Posted Aug 21, 2013 07:54 AM

    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?



  • 2.  RE: Handling certificate expiration
    Best Answer

    Posted Aug 21, 2013 07:35 PM

    > 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.

     



  • 3.  RE: Handling certificate expiration

    MVP
    Posted Aug 22, 2013 02:48 AM

    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?

     



  • 4.  RE: Handling certificate expiration

    MVP
    Posted Aug 23, 2013 02:41 AM

    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?



  • 5.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Aug 23, 2013 02:46 AM

    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.



  • 6.  RE: Handling certificate expiration

    MVP
    Posted Aug 23, 2013 05:20 AM

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



  • 7.  RE: Handling certificate expiration
    Best Answer

    Posted Aug 29, 2013 12:50 AM
      |   view attached

    > 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.

     

    Attachment(s)

    zip
    AuthSource.zip   809 B 1 version


  • 8.  RE: Handling certificate expiration

    MVP
    Posted Sep 02, 2013 12:26 PM

    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.



  • 9.  RE: Handling certificate expiration
    Best Answer

    Posted Sep 02, 2013 11:56 PM

    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.

     



  • 10.  RE: Handling certificate expiration

    MVP
    Posted Sep 03, 2013 04:30 AM

    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:



  • 11.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Sep 15, 2013 06:36 PM
    With the patch that went out Friday this should now work. I tested in my lab and it all looks good. Can someone else test and verify.


  • 12.  RE: Handling certificate expiration

    MVP
    Posted Sep 17, 2013 08:58 AM

    Yup, very happy camper here as it is now working... woohooo!

    The patch did crash the cppm server but meh it needed a reboot to apply the patch anyway :P

     

    Kudoed and marked as solved!



  • 13.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Sep 24, 2013 06:57 PM
      |   view attached

    One other note on this, that I was just reminded today is

     

    Onboard will only issue a new certificate during device reprovisioning if the old one has less than 25% of its life remaining.

     

    Attached is the auth source. Import auth source Password: 1

     

    Make sure you change the auth source password to your appadmin password.

     

    1 Day

    1 Week

    2 Weeks

    3 Weeks

    Attachment(s)

    zip
    TimeAuthSource.zip   863 B 1 version


  • 14.  RE: Handling certificate expiration
    Best Answer

    EMPLOYEE
    Posted Jan 29, 2014 05:35 PM

    To update this post. 

     

    You now have two options or you can use both.

     

    1. The role chage (per Dave post) to force users to get a new cert

    2. Email noification (in 6.3) to let the user know there cert will expire soon. See screen shot

     

    certnotification.png

     

    certnotification2.png

     



  • 15.  RE: Handling certificate expiration

    Posted Jan 29, 2014 07:22 PM

    This is a great new additions.  Really makes things easier, but...

     

    Let's assume that the user does not immediately renew their cert.  Can you setup a follow up email to go out if x amount of time passes and the cert has not been renewed?  This would be similar to a Windows computer joined to a domain, where the password policy prompts you to change your password x amount of days before your password expires, and up till the expiration date if the user ignores the prompt.



  • 16.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Jan 29, 2014 07:29 PM

    An email goes out each night until the cert either expires or is renewed. 



  • 17.  RE: Handling certificate expiration

    Posted Jan 29, 2014 07:30 PM
    Perfect!


  • 18.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Jan 29, 2014 07:32 PM

    One other note is where you can use the the two options together. 

     

    The email goes out starting at two weeks before it is expired and if they don't renew you can set the system at one week before it expires to force the user to a role that would push them to the onboading page. 



  • 19.  RE: Handling certificate expiration

    Posted Sep 08, 2014 07:59 AM

    After certificate expirey, how clearpass will send a mail to that particular user.

     

    How it fetches the email address.

     

    is there any additional configuration required????



  • 20.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Sep 08, 2014 08:31 AM
    In your onboard configuration, you specify how it gets the address and when it will send the email.


  • 21.  RE: Handling certificate expiration

    Posted Sep 08, 2014 09:21 AM

    hi

     

    i could see only to check notify users before credentials expire.

     

    But how clearpass will know the email address of the user?

     

     



  • 22.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Sep 08, 2014 09:56 AM

    It uses the email field from the certificate. See below for the overrides:

     

    onboard-provisiong-settings.JPG



  • 23.  RE: Handling certificate expiration



  • 24.  RE: Handling certificate expiration

    Posted Sep 09, 2014 12:57 AM

    tanq

     

    but is there is any way to send mail from clearpass to  user that your credentials are going to expire..and suggesting to reprovision your advice???



  • 25.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Sep 09, 2014 01:03 AM

    Yes that is what Tim posted above. 

     

    Or look at page two in this link

     

    http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Handling-certificate-expiration/td-p/93548/page/2

     

     



  • 26.  RE: Handling certificate expiration

    Posted Sep 09, 2014 05:46 AM

    @cappalli wrote:

    It uses the email field from the certificate. See below for the overrides:

     

    onboard-provisiong-settings.JPG


    ok i got it. this is if clerapass cannot fetch email address.

    but in my site. Username and email id differs. Is there it can fetch email address from AD to send mail prior 4 weeks of expiry.

     

    Warm Regards

    Srikanth Soogoor



  • 27.  RE: Handling certificate expiration

    EMPLOYEE
    Posted Sep 09, 2014 06:00 AM
    When the cert is created it embeds the username in the cert. the only way today is to have them put in their full username when the cert is created. Username: tarnold@company.com

    I would suggest you file a feature request. I've already have asked engineering to have this feature expanded but it also helps to have customers also ask to get it into an earlier release.


  • 28.  RE: Handling certificate expiration