9611G Identity Certificate Renewal

[trilogy8]

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.

 

[kyle555]

This note shows you how to set up a SCEP relay on the SBC.

https://www.devconnectprogram.com/fileMedia/download/126eedb4-5195-497b-8244-2b05def0b03a

Once the cert expires, the phone will (should?) ask for another

 

[trilogy8]

Thank you, I'll have a read through.

 

[trilogy8]

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.

 

[kyle555]

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?

 

[trilogy8]

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?

 

[trilogy8]

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?

 

[trilogy8]

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.

 

[trilogy8]

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.

 

[kyle555]

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.

 

[trilogy8]

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.

 

[kyle555]

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

 

[trilogy8]

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.

 

[kyle555]

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!

 

[trilogy8]

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?

 

[kyle555]

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:

 

[trilogy8]

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.

 

[kyle555]

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.

 

[trilogy8]

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.

 

[marcuspb]

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?)