This sounds like the same problem a few of us had with the apple 10.7.4 update. Ted Roberge from UCI posted this solution a couple months ago, I would check these first. Cut and paste of his post follows: Here at UCI I think we found a permanent fix. We tested what I feel is a fix for this problem. Simply put, we needed to add the following hosts in both the temporary and unauthenticated roles; (user roles->Policies ->Unauthenticated and temporary -> Host). This problem, according to many blogs and posts, affects systems that are primarily behind proxy’s or NAC devices. The CA simply could not phone home. crl.thawte.com ocsp.thawte.com crl.verisign.net ocsp.verisign.net crl.usertrust.com ocsp.usertrust.com crl.incommon.org ocsp.incommon.org We use Thawte certificates, but you should make entries based on your specific certificates (comodo?). We did add in Verisign just to be safe. This was developed by our team here at UCI and then tested and verified by our Cisco TAC manager. >>> Dennis Xu <[email protected]> 7/9/2012 7:45 AM >>> We have CAM/CAS 4.8.2. We installed the chained certificates from Thawte to CAS servers. Recently some Apple Safari wireless users complain about the certificate warning "invalid certificate issuer" when opening web browser. The same Apple users do not see the warning when opening browser using Firefox. These users also do not see the warning when accessing our email server(installed the same type of certificate from Thawte) using Safari. Any ideas?
--- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217
