This message was deleted.

Didn't globalsign withdraw the G2 intermediate back in january 2021 for all DV certificates? i recall we had the issue and had to replace the G2 intermediate with R3 (and re-deploy certs)

Sorry about that. That screenshot was just for a reference. We got exact same issue on entrust cert. Removed it now. I have meeting with entrust in sometime. I m going to discuss about this: https://support.citrix.com/article/CTX205729 not sure if that helps though..

MACS have always been sensitive to certificate chaining make sure your SSL cert is linked to the intermediate cert and intermediate cert is linked to the root on your ADC. I normally check the cert chaining/installation via sslshopper afterwards at https://www.sslshopper.com/ssl-checker.html

we've already used sslshopper and ssllabs as well for testing the certificate. Initially, sslshopper said intermediate cert has problem, but we fixed it with entrust. But still we had the same problem. Thats when we changed https to http on the manage delivery controllers option.

This is what the chaining should look like

That is exactly how it shows now for our netscaler gateway.

changing from https to https on your manage delivery controllers on the storefront stores would only impact the XML traffic between the Storefront servers and the DDC's. You would have certificates in the personal cert store on your DDC's and have the cert binded via IIS bindings or via netsh

exactly thats my point. SF to DDC is only till launching the ica file in user's machine. After the file is downloaded, communication is from user's machine to netscaler and netscaler to DDC (to verify STA), then ddc to app server...

once the ICA file is downloaded it will connect to the NS GW (ssl proxy host) NS GW validates the STA with the DDC and then connects to the VDA

correct, storefront is not in the list. But we get error only when users click on the ica file. Now, disabling the https on sf delivery controllers node, only changes the way how xml works. on https it uses ssl, but after disabling https, it uses http on 80.

the new cert that you installed did you make sure the root ca cert that issued the cert was installed on your SF servers in the trusted root ca store? I have seen issues in past with NS callback urls where the cert that the callback url uses wasn't trusted by the storefront servers. Did you have a look at the keychain on one of the MAC's ? was the intermediate and root listed ?

no, we did not install any certs on storefront. we only installed new certs on netscaler.

is the cert trusted by the mac endpoint? normally this is an issue because the intermediate isn’t in the list of trusted certs on the mac

If we install intermediate cert on macbook manually, it resolves the issue, but we have almost 3-400 macbooks.. so want to fix it from server end.

if they don’t trust your cert, you can’t

Thats the problem

so if mac os doesn’t distribute your intermediate cert by default then you’re out of luck, you need to touch the endpoint or get a cert that’s trusted by defualt

If your root cert is L1 M, can you have an L1 K intermediate cert? or both should be either L1 M or L1 K ?

Can you get the pfx bundle from your cert provider? it should contain the full correct chain

yeah, looks like

which seems weird as it’s been out for years, but if you google entrust and mac there’s loads of complaints so…

sorry for the delay.. one other point is, when we had the issue, we have turned off all components but left only one netscaler, one sf, one ddc powered on. Not sure from where, but we got L1 M in the error message when we have installed L1 K everywhere. Does macbook cache certificates somewhere? Does receiver cache certificate information? Does netscaler store/cache certificate information? only question that isnt answered is, when there is L1k everywhere, how did we get L1 M in the error? If it is L1 K, that makes sense..

my guess is that the cert on the netscaler wants to be linked to an l1m intermediate cert

we already did that. On the netscaler, we linked server cert to intermediate cert.

I guess we need to take a step back and work out exactly where it is failing. You said it only happens when you secure the XML traffic on the DDCs right? They talk back to the SF servers, so I would start looking at logs on both when the failure happens. 9/10 times it’s DNS, but you also mentioned you didn’t put any certs on Storefront, which makes me think it probably doesn’t trust the SSL traffic coming from the DDC as it may not trust the root cert by default and possibly the chain on the DDC is incorrect.