Secure Access Analyzer - Proxy Agent Communication Using Organisations CA

Products Access Analyzer Ideas
,
1

What is a one sentence summary of your feature request?

Allow us to use our own certificates that are generated by our own CA

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

Its standard for most large organisations to not allow the use of self-signed certificates yet we will have to when we upgrade to the later versions of Access Analyzer we will have to use certificates that the product generates which are classified as self-signed certificates.

We need to be able to use our own certificates that are password protected by default.

How do you currently solve the challenges you have by not having this feature?

Presently this isn’t a problem as the version we use doesn’t need certificates, however when we upgrade we will have to raise exceptions that are tracked by our internal risk team for the fact we are using self-signed certificates.

1 Like
2

Hi Mark!

If I understand your ask correctly, this is already a feature of the Access Analyzer product! You can find more information on this in our Help Center, here: FSAA Applet Certificate Management Overview | Netwrix Product Documentation

Specifically, under “Provide Certificate Authority”. It should be available in both NAA v11.6 & v12.0.

1 Like
3

Hi Tay, thanks for your advice and the link. I have read that a few times and I do have a few questions:

If we use our own CA can you explain the certificate exchange process? For example, do we upload the root cert, the intermediatory CA and the server & client certificates into a certificate store manually on the NAA server? Then does the data collector job distribute the certificates on our behalf? If so, how does it know what cert to distribute considering we have many agent servers?

Or do we need to manually add the root cert, intermediatory CA and client cert onto the certificate cert on the client servers?

If that is the case, considering our agents service runs as local System, where do we place the certificates?

And if certificates have to be installed manually into a certificate store, why can’t password protected certs be used? When we download our certs from our internal portal we have to password protect the certificate. However, that password is only needed when installing the certificate. Once installed the password is of no consequence.

Kind regards

Mark

4

Hey Mark!

If you’re using your own CA with the “Provide Certificate Authority” option in FSAA, you don’t need to manually install any certs on the agent machines.

You just provide a single PFX file (without a password) that contains your CA certificate. FSAA takes care of the rest! It will generate a unique client certificate for each agent and push it out automatically. You don’t have to upload root or intermediate certs to the remote systems, FSAA handles that behind the scenes.

As for password-protected PFX files: FSAA runs unattended jobs that load the CA programmatically. There’s no way to supply a password at runtime, and .NET cannot load a password-protected PFX without user input — that’s why the PFX must be created or exported without a password.

5

Hi Tay, thanks for your advice. I am checking with our cryptography team on whether we are able to obtain a certificate that fits the bill.

In the meantime, do you have a link or any documentation on this that goes into more detail?

Regards

6

Hey Mark! Apologies for the delayed response, but I wanted to get something official published for you. The page below includes more details on the “Provide CA” option and using either the provided FSAACertificateManager.exe or PowerShell to generate a certificate, but any other third-party tools like Digicert or Windows Enterprise CA can generate the certificate provided the certificate meets the listed requirements.

1 Like