Skip to main content
  • EN

Hello,

 

I am seeking some guidance as to how/where Netskope certificate files are imported onto MacOS. We have had numerous issues with Deloitte practitioners (mainly developers and individuals running code/CLI) where the Netskope cert prevents the application from running due to residing atop the cert chain, and therefore is not trusted by the application service. We have copies of the cert files (ca.deloitte.eu.goskope.com and caadmin.netskope.com) and have set the cert to Always Trust in Keychain; however, SSL errors are still being returned by the system. An example is below, using the brightcove.com service:

 

2022-09-27 09:10:16.604476-0600 USGA Dev[2698:26211] Task <BB14C893-A867-4C5C-977F-8624C991653B>.<1> finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=(

    "<cert(0x7fde7b11ba00) s: *.brightcove.com i: ca.deloitte.eu.goskope.com>",

    "<cert(0x7fde7b069000) s: ca.deloitte.eu.goskope.com i: caadmin.netskope.com>",

    "<cert(0x7fde7b069800) s: caadmin.netskope.com i: caadmin.netskope.com>"

 

I'm looking for any information as to how the above can be resolved without inputting an SSL bypass, as it is clearly related to untrusted agent certificates.

 

 

 

Regards,

Marc-Anthony

Hi Marc-Anthony,


In the case of applications used by developers, some settings require attention:

 

a) If the application in question has its own CA store.
b) If the application in question requires setting up the variables where to find the CA store.
c) If the application uses Curl or Wget.

 

Here the examples of Curl and Wget settings:
echo "cacert=<Path to Certificate>/rootCA.pem" >> $HOME/.curlrc
echo "ca_certificate=<Path to Certificate>/rootCA.pem" >> $HOME/.wgetrc

 

I hope this helps.

 

Best regards

 

 

Hi Adrian,

 

Thanks for the information, that makes sense. We are aware of the CA store process for Windows, but the Mac application stores have not been as easy to identify. The user also isn't sure if the application uses Curl or Widget, but I am planning on reaching out to the application vendor for a Mac use case; they should have familiarity in the areas of identifying and setting up of variables for the CA.

 

Thanks for the help!

 

 

 

Regards,

Marc-Anthony

Here are some variables that are used within our environment.  A certificate is pushed via JAMF (or whatever MDM) to a specific path, and then the variables were pushed to .zshrc or .bashrc:

 

export REQUESTS_CA_BUNDLE="$HOME/.path_to_cert.pem"
export NODE_EXTRA_CA_CERTS="$HOME/.path_to_cert.pem"
export AWS_CA_BUNDLE="$HOME/.path_to_cert.pem"
export GIT_SSL_CAPATH="$HOME/.path_to_cert.pem"
export CURL_CA_BUNDLE="$HOME/.path_to_cert.pem"

That actually might help, as we use JAMF for policy management/administration. I will need to double check the application path with the developer. I'll pass that along to our Mac team. I appreciate it! 

Let me know if you need script sample on what we did. We had a mix of .bashrc as default vs. zsh. 

So to provide an update, our JAMF team actually revealed that the certs we have for NS are not marked as "allow all apps access"; it is possible that the JAMF config may be overriding the machine/user certificate trust settings set, at those levels, causing the error output despite the certs being trusted in Keychain (which would explain why, when we switched that toggle, it didn't work). 

 

We are pending a call to verify if changing that setting at the global configuration level affects the trust-ability of the certs with respect to the application - hoping that it does. Will keep the thread updated. 

 

Thanks! 

Hello all,

 

To close the loop on this (for the few folks that might've been following 😊), we worked with our internal teams to comb the Netskope logs and the issue ended up being a configuration update pertaining to the certificate pinned bypass function. The application processes making calls to the URLs needed to be added to the existing cert pin bypass list in order for Netskope to allow that traffic, which took care of the issue; there was no variable/reference to the certificate locations, themselves, that needed placing into the code.

 

Hope this helps others that might run into this issue! Here is the article, for reference: https://docs.netskope.com/en/certificate-pinned-applications.html

Reply


Terms & ConditionsCookie settings