×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

9611G Identity Certificate Renewal

9611G Identity Certificate Renewal

9611G Identity Certificate Renewal

(OP)
I'm preparing to deploy remote 9611G SIP hard phones to some users. We initially provision the phones internally where they are set to use SCEP to be provided an identity certificate from our internal PKI infrastructure. The certificates have a 2 year life and once deployed we want to ensure they will automatically pull an updated certificate before expiration. I see in the 46xx file a setting for MYCERTRENEW. I understand what that settings means, but will the phone in fact trigger a request for a new cert or will it just flag a warning? If it's the latter is anyone currently auto renewing certs for these? A major pain point for us is when certificates expire the phone becomes unusable and the user has to be provisioned a new one, which is not welcomed.

RE: 9611G Identity Certificate Renewal

(OP)
Thank you, I'll have a read through.

RE: 9611G Identity Certificate Renewal

(OP)
I'm still having challenges with this working. I have the 46xx.settings file setup properly for the phone to go through the SCEP process to pull an Identity cert from our CA. I have the phone registering successfully through the SBC over a regular internet connection. Our internal teams setup a certificate policy where the certificates provided to the phones only have a 48 hour life span. In the 46xx.settings file I have 'MYCERTRENEW 1'. My understanding of that setting is the phone should look to renew its certificate at 1% of the validity period. In this case of a 48 hour cert that should be about 45 minutes. This is not working. Even if I reboot the phone within the validity period it doesn't pull an updated cert. If I reboot it after the cert expires it fails at the SBC.

On the SBC I setup DMZ/Relay/Application Relay with the service type as: SCEP, the remote config IP of our certificate server:1023 and the listen IP/port as the external IP of the SBC:1023 (B2)and the connect IP of the internal facing IP on the SBC (A2). 1023 is opened on our external facing FW and is also opened between A2 and the certificate server.

Is there anything I'm missing? The only thing that came to mind is the certificate server, which is running on Windows doesn't have 1023 opened on the Windows FW. Not sure if that's actually necessary.

RE: 9611G Identity Certificate Renewal

Why wouldn't 1023 on the Windows firewall be necessary? If the SBC is relaying SCEP on 1023 to the Windows box, it would stand to reason that traffic has to be allowed through.

What if you did something like "tshark -i any port 1023" on the SBC and see if the phone is in fact sending a request and if the SBC is in fact relaying it?

RE: 9611G Identity Certificate Renewal

(OP)
Does the relay on the SBC work the same for the SCEP process as it does for the firmware where I can listen on 1023 on B2 and on 80 to the destination certificate server?

RE: 9611G Identity Certificate Renewal

(OP)
I can't seem to get through this hurdle. For the identity cert we've reduced the cert validation length to 24 hours and 18 hours within that period for it to offer a new cert. That comes out to 6 hours. In my 46xx file I set the MYCERTRENEW to 25. If I understand that setting correctly that should be also 6 hours. We had a capture running on the internal server that offers the certificates and at the 6 hour+ mark there was no traffic. Should the phone with that setting at 25 automatically start polling for a new cert and if for some reason it was unsuccessful does it keep trying?

Also, on the SBC I understand port 1023 is the SCEP listening port, but is it supported to have the B interface listen on 1023 and then send the request from A to the certificate server on 80?

RE: 9611G Identity Certificate Renewal

(OP)
Sorry for this pestering thread, but I'm even having difficulty with Avaya on this. This time I had the phone once again provisioned with an identity certificate that was valid for 24 hours. My settings file has the 'SET MYCERTRENEW 25', which I'm of the understanding that is saying to begin looking for an updated certificate after 6 hours. This time I also tried to eliminate the SBC and launched the phone on the internal network and directly to Session Manager. I ran a traces and turned on debugging on the endpoint to Splunk. At the 6 hour mark there was nothing in the SM trace and I'm still going through the Splunk data, but I'm not expecting to see anything. I assume this isn't an SBC issue anymore and down to the endpoint. If anyone is currently doing this successfully I'd appreciate any guidance on how.

RE: 9611G Identity Certificate Renewal

(OP)
I spoke out of turn in my last message. The phone did renew the certificate, but it renewed every 20 minutes. That's a huge breakthrough that I know it works, at least internally, and can now branch back out to the SBC. What I don't understand are how these timers are working. As I mentioned the certificate has a 1 day validity period and in the settings file the MYCERTRENEW is set to 25. Unless I'm misinterpreting what that setting is, I expected this to not attempt a renew for 6 hours. Seems like it's something off in the file and I'm not seeing what.

RE: 9611G Identity Certificate Renewal

The only thing i can see in there is a renew timer - at what % of the cert life being used up should it try again - so, by definition that would mean it has to take the cert, do math "valid until" - "valid from" = hours cert is good. Multiply by that % in MYCERTRENEW and that's when it should try again.

Just for laughs, check the identity cert's "valid from" date. You'd like to think it would be a timestamp of when the cert was actually generated, but it would just make life fun if it weren't the case!

I just checked a cert I generated in SMGR and it backdates the validity by 10 minutes. To say, a cert I generated at 1030 is valid from 1020 today. I think it's to account for if your clock is slow, you won't get hooped when you try loading a cert that isn't 'yet valid' because you're a few minutes behind.

If whatever CA you're using backdates further than that, maybe 25% of 'total validity time' comes up quicker than you think.

RE: 9611G Identity Certificate Renewal

(OP)
What I'm struggling to understand is how the phone learns about the file transfer / SCEP IP address. I know they are configured in the SBC with ReverseProxy and AppRelay, but they aren't defined in the settings file.

RE: 9611G Identity Certificate Renewal

Yes they are... MYCERTURL is where the phone will go. So, SBC Public IP, or split FQDN where the internet sends yourscepserver.com to the SBC for the relay and your DNS inside sends yourscepserver.com to your internal SCEP server

RE: 9611G Identity Certificate Renewal

(OP)
That's probably my issue with that MYCERTURL only having a path with an internal server IP. If that line is changed to the public IP or split DNS name, ideally we'd like to have the AppRelay be able to listen on 1023 of the B interface and then 80 toward the internal. I don't see how that would be possible if the MYCERTURL line sounds like it would have to have :1023 defined in it. That internal certificate server would then need a 1023 binding to be able to provision the phone on the internal network.

RE: 9611G Identity Certificate Renewal

Pretty much. Unless you can live without having port 80 on the public IP, in which case you can probably just have the phone always reach to port 80 and have the SBC relay that to port 80 on the inside

Split DNS is easy until you want to use different ports on the inside and outside!

RE: 9611G Identity Certificate Renewal

(OP)
To circle back on this thread.. I've made a bunch of progress from the guidance, so thanks for that. I do have one issue I'm still not able to solve and that's the frequency the phone is requesting and getting updated certificates. For our testing the certificate template was modified to provide certs with 24 hour validity. In the 46xx file the MYCERTRENEW is set to 90. Unless I'm misinterpreting what that indicates, I thought it meant the phone will start requesting an updated cert at 90% of the cert validity length. Based on that, 90% of a 24 hour cert is in an around 21 hours. The phone is requesting/getting a new cert every 13 hrs and 27 mins, exactly. Is there another setting somewhere I'm missing or am I incorrect about what the '90' is supposed to do?

RE: 9611G Identity Certificate Renewal

Reading it, it's fuzzy...
I get what "50" would do, but what if you try 1 phone at 25 and another at 75? You'd think one would renew after 6 hours and the other 18.
Is it "renew once 25% of total validity period elapsed"? or "once 25% of period is left"?

I don't know if I mentioned it earlier in the thread, but I see SMGR seems to backdate certs by 15-20 minutes as well. Just to make sure if you enroll and you're a couple of minutes behind that you don't puke and complain that the cert isn't valid yet. Play around. Maybe you've got a good case to make with Avaya or a bug or design intent that "it won't do it more than once every 12 hours no matter what you do" or something.

## MYCERTRENEW specifies the percentage of the identity certificate's
## Validity interval after which renewal procedures will be initiated.
## Valid values are 1 through 99; the default value is 90.
## This parameter is supported by:

RE: 9611G Identity Certificate Renewal

(OP)
We provision the phones using our own PKI. At one point I did have that MYCERTRENEW set to '1' and the phone was getting a new cert every 15 or 20 mins, so the interpretation seemed as it fit your first statement "renew once 25% of total validity period elapsed". We then changed it from 1 - 90 and it went to the 13hr 27min mark. That math says its doing it a bit above 50%. On a 2 year cert that sounds like it would be doing it after a year or so. I guess not the end of the world, but would be leary of deploying these that way.

RE: 9611G Identity Certificate Renewal

What is the issue date/time in your PKI vs the timestamp of the request? I'd think it's a pretty common and sane practice to backdate the issuing time by some amount just to account for clients that are a few minutes behind your CA so they don't fail and get a cert valid from Noon when they think it's 11:58.

I wonder if the phone does some funky math based on that.

RE: 9611G Identity Certificate Renewal

(OP)
The only thing I question is our PKI is based out of the US and the phone lives in our APAC region, which is 12/13 hours ahead.

RE: 9611G Identity Certificate Renewal

How is the server figuring in the GMT offset? (I'm just a casual observer to this interesting thread btw so I'm sure it's not this simple but who knows?)

RE: 9611G Identity Certificate Renewal

Ooh. maybe you nailed it.

AFAIK, Windows and everything shows you the cert "valid from/to" in local time, but the spec should be to do it in GMT.

So...lets think...

It's March 8, 8h00 EST (GMT-5), that's 13h00 GMT, and 21h00 (GMT+8) in Asia if 13 hrs ahead

Cert is valid from March 8 13h00 GMT->March 9 13h00GMT
Renewing every 15/20 mins at 1% is fine, that's about 1% of a day no matter what


13h27min = 807min. A day is 1440 min.

The phone should be renewing 1296 minutes after getting a cert and not 807 minutes. That's 489/490 minutes, or 8hrs10mins early.

You'd expect the phone to renew 21h36min after it got the cert, not 13h27min

So, if the phone was stupid and got it's cert at 13h00GMT/21h00GMT+8, and thought it was only good from 21h00-->13h00 the next day (16 hours or 960minutes), then it would renew at 90% of 960min, or 864 minutes later.

If the phone is in GMT+7 or 12 hours ahead of GMT-5...
The cert would be good from 20h00 -->13h00, that's 17 hours, 1020 minutes, 918min till renew, which is 15 hours 18 mins.

If the phone is in GMT+9
The cert would be good from 22h00-->13h00, that's 15 hours, 900mins, 810 minutes to renew. And you're at 807 like clockwork, eh?

If your CA backdates the cert a few minutes to account for slow PKI clients and you're phones are in GMT+9, I think we might have figured it out.

If the phone has a bug where it considers the cert's 'valid from' expressed in GMT as "local time" and "valid to" in true GMT, then the phone would renew sooner.

Here's what you can do - take a settings file, set the timezone of a test phone in Asia to GMT, see if it behaves.
Set the RENEW of a GMT+9 phone to "50" - if I'm right, then it should be "half" of the 900 minutes - 450min, or 7 and a half hours.

RE: 9611G Identity Certificate Renewal

(OP)
Before you replied, what I actually did was change the offset in the settings file to -5, which is US. If the time is the issue then this phone should follow the 21h36m path, give or take a few.

RE: 9611G Identity Certificate Renewal

(OP)
so much for that.. I didn't get 21h36m, but got about 15h43m. Better. I guess it's something I can probably just move forward with. When these get moved to the normal 2 year certs this should be barely noticeable. Going to try extending the cert validity to about 4 days to see if this time remains consistent or extends further out.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close