ASBCE r7.2.2 - Remote Workers - no TLS Server Hellos

[vtt2019]

Hi Sirs:
I have the same problem described here:

https://www.tek-tips.com/viewthread.cfm?qid=1775207

I am using ASBCE r7.2.2 and IPO r11.0.4. I created an Identity Certificate for SBC (*.p12 first, then splitted to SBC_ID.crt and SBC_ID.key) in IPO Web Manager using its Public IP Address (B1 port), Subject=FQDN-SBC, SAN=DNS:FQDN-SBC,IPublicIPAddress-SBC. I uploaded SBC_ID.crt (plus signature) to SBC. Then I configured a TLS Server Profile (using SBC_ID.crt and SBC_ID.key - enabling all TLS 1.x versions). I created a Signaling Interface (external) using that TLS Server profile and finally I configured a Subscriber Flow based on that Signaling Interface (external).
For testing, I used Avaya Communicator r2.1 softphone. First, I tested a connection from softphone (through SBC) to IPO with TCP 5060. It works fine as expected. When I change to TLS 5061 (and running traceSBC), I see TLS Client Hellos coming from softphone and arriving at SBC (B1 port) but no TLS Server Hellos from SBC (no answer at all). Please check attached screenshots. I had a similar problem in Aura, it was the TLS version in SM but in this case I allowed all versions in SBC (??). I have tried many ways to regenerate the SBC Identity Certificate and TLS Server profile without success.
Please help me or guide me with an example (a screenshot of your IDENTITY CERTIFICATE.

 

[kyle555]

lookup certsync in the knowledge base. There's stuff with certs that just cause you do it in the gui and reboot doesn't means it sticks. Especially at 7.2.2. no server hello = no known config to use = your config didn't actually get put in there even though I'm sure it's correct in the gui

 

[vtt2019]

Hi Kyle555:
I did two things:
1) Per your comments, I made an upgrade to r7.2.2.3 (last one available.
2) As ROOT user, I applied these commands: (Both were missing in an Avaya SBC config guide I was using as reference, very bad!!)
# cd /usr/local/ipcs/cert/key
# enc_key SBCE_ID.key "Passkey"

Please, could you explain what it does that second command (enc_key)?

 

[kyle555]

enc_key --> the private key when you generate a CSR in the SBC has a passphrase you set when you generate the CSR. SBC is stupid and doesn't remember that when you feed the cert in and that'z why it never takes.

I've always used openssl to generate my keys/csrs/p12s and fed back unencrypted keys to the SBCs webpage. Otherwise it burns me.

I've been screwing around with UC reverse proxy stuff for equinox on 7.2.2.2, 7.2.2.3 and 8.0.1 all week. Single server, HA SBC under 1 EMS. Whole deal.

Pull your hair out. The TLS configs just corrupt and crap all over each other.

As in, I used a SMGR signed cert with SANs for aads.lab.com, breezepresence1.lab.com, breezepresence2.lab.com, etc. Worked great.

Got my Let's Encrypt public cert. I used that public cert and replaced it in the server profile facing outside. You'd like to think that it would just make the SBC use the different cert externally. Instead it corrupted everything.

Solution articles say the only sure thing is to delete your reverse proxies. I had some luck changing everything SIP TLS 5061 to TCP 5060, reboot, change back to 5061 with the cert and reboot again.

Sometimes service nginx-data restart and then reload and then restart again helps.

Still, the SBC is trying mutual TLS authentication as a client inward toward session manager and offering a certificate of 0 bytes.

Any time I change anything I get incidents of sslv3 handshake errors.

Just start over. Hit it with a hammer. It's the only way to be sure.