Connection to Url retrospective service failed

[sv7]

Hi Team,

I have done an upgradation from 14.2.1-020 to 15.0.0 build 104 and after that facing an Error "Connection to Url retrospective service failure due to invalid certificate". Please find attached snap and let me know how can i resolve this.

[UdupiKrishna]

If you are not using a proxy, ensure ESA can resolve and connect to these URL(s) on port 443.

• prod-register-api.uce.cmd.cisco.com

• prodap-retro-api.uce.cmd.cisco.com

• prodeu-retro-api.uce.cmd.cisco.com

• produs-retro-api.uce.cmd.cisco.com

[sv7]

We are using proxy. How should we test connectivity to above url in that case ?

[Ken Stieers]

That connection to the URL rerro.service is HTTPs. Is your proxy decrypting?

If so, you either need to exempt the ESA from being decrypted, or add the root that the proxy uses for generating its certs to the ESA, just like you had to do for workstations (and that still might not work)

W used to use WSA, and we put the ESA in bypass.

[sv7]

I have checked and able to connect all 4 Url's, but still getting the Error of invalid certificate as per prevoius attachment. What could be the next i can do to resolve this ?

[miani]

Just had a chat with TAC about this. A fix for this is scheduled for release 15.0.2 and 15.5.1. The Defect CSCwi59220 will soon be updated and the fixed releases will be out at the end of April.

[saliyev]

@sv7 does issue still persist and do you need assistance or it has been resolved?

[Aljosa Pocic]

I'm still facing tje issue. I check and version 15.0.2 or 15.5.1 are not available yet. Latest version I can see is:

1. AsyncOS 15.0.1 build 030 upgrade For Email, 2023-11-22, This release is a
Maintenance Deployment

[charella]

Aljosa Pocic,
Did you upgrade yet?
15.5.1-055 ESA was released Tuesday 2 May.
We’re curious if your alerts stopped.

[saliyev]

@sv7 , as mentioned by @Ken Stieers , probably session hits SSL Decryption policy in your proxy server.
you can do a packet capture on ESA (navigate to 'help and support' -> 'Packet Capture' page, set relevant filters [f.e. server IP address]), take capture, analyze it by wireshark and here try to find out relevant session, find and check certificate details provided by server during TLS handshake process to figure out by whom provided certificate. you can also share pcap file or some screenshots here.