Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 7 subscribers
  • Views 4539 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SafeGuard on Mac SSL Verification and SSL certs in keychain

EricWoelfel

From my understanding, when you update a certificate for SSL communication on the SafeGuard Management Center then you have to update it on each of the MAC clients. We get our certificates from an official authority (not self-signed) but they are only good for 1 year. Therefore, if SSL verification is enabled on the the client then I would assume I'd need an up-to-date cert for proper communication. 

I can't seem to figure out how to get an error on this. I've tried using old certs that are expired, no certs at all; all while the SSL verification on the Mac is turned on. What exactly is the cert used for on Macs? You do not need to update the cert on Windows computers so I'm curious as to why the Macs need the certs updated. Thanks for the clarification. 



This thread was automatically locked due to age.
Parents
  • +1

    Hi Eric,

    SafeGuard communication is no different from any other SSL communication. That is, the client needs to verify the identity of the server, which it does through the certificate presented by the server. With SafeGuard, in the majority of cases, the certificate is either self-signed or issued by an internal CA. In the case of self-signed, the server certificate must be deployed to all clients as a Trusted Root certificate. For certificates issued by an internal CA, the CA root certificate should already be deployed to all endpoints.

    When these certificates are nearing expiry or have expired you need to re-issue the certificate to the server in question. For environments using an internal PKI, this is not a problem as the internal CA is trusted and hence all certificates issued by the CA are implicitly trusted. So, no need to update the clients. In the case of self-signed certificates, you would need to deploy the new certificate to all endpoints before the server would be trusted.

    If, as you say, you use certificates issued by public CA's, e.g. Thawte, Verisign, Comodo, all of this is handled by the provider, CRL's are publicly available and fully maintained and the Trusted Root certificates should be automatically updated by OS updates, although this is not always the case for some vendors. Hence, all you should need to do is ensure the SSL certificate on your SGN server is up-to-date and all should be fine.

    I'm not too familiar with Apple devices, so take the following as assumptions on my part. I know the MAC admin guide says you need to import the SGN server certificate to the keychain and always trust for SSL, I don't think this step would be necessary for publicly issued certificates. You could test this by not installing the certificate and browsing to https://<sgnserverfqdn/sgnsrv, you shouldn't get an SSL error. Perhaps, you could skip this step and see if things still work.

    However, if you're able to use an expired certificate without any errors, I'd take a look a the settings on your Mac's. I'm no expert with Apple devices, but you should get an error for an out-of-date certificate, I would have thought.

    Let me know if this makes sense.

Reply
  • +1

    Hi Eric,

    SafeGuard communication is no different from any other SSL communication. That is, the client needs to verify the identity of the server, which it does through the certificate presented by the server. With SafeGuard, in the majority of cases, the certificate is either self-signed or issued by an internal CA. In the case of self-signed, the server certificate must be deployed to all clients as a Trusted Root certificate. For certificates issued by an internal CA, the CA root certificate should already be deployed to all endpoints.

    When these certificates are nearing expiry or have expired you need to re-issue the certificate to the server in question. For environments using an internal PKI, this is not a problem as the internal CA is trusted and hence all certificates issued by the CA are implicitly trusted. So, no need to update the clients. In the case of self-signed certificates, you would need to deploy the new certificate to all endpoints before the server would be trusted.

    If, as you say, you use certificates issued by public CA's, e.g. Thawte, Verisign, Comodo, all of this is handled by the provider, CRL's are publicly available and fully maintained and the Trusted Root certificates should be automatically updated by OS updates, although this is not always the case for some vendors. Hence, all you should need to do is ensure the SSL certificate on your SGN server is up-to-date and all should be fine.

    I'm not too familiar with Apple devices, so take the following as assumptions on my part. I know the MAC admin guide says you need to import the SGN server certificate to the keychain and always trust for SSL, I don't think this step would be necessary for publicly issued certificates. You could test this by not installing the certificate and browsing to https://<sgnserverfqdn/sgnsrv, you shouldn't get an SSL error. Perhaps, you could skip this step and see if things still work.

    However, if you're able to use an expired certificate without any errors, I'd take a look a the settings on your Mac's. I'm no expert with Apple devices, but you should get an error for an out-of-date certificate, I would have thought.

    Let me know if this makes sense.

Children
No Data
Unfiltered HTML