NFA: ApplyHTTPS Tool

Products

• CA Network Flow Analysis (NetQos / NFA)

Issue/Introduction

In order to simplify and streamline applying HTTPS/SSL to DX NetOps Network Flow Analysis and Application Delivery Analysis, the DX NetOps Support team wrote the ApplyHTTPS tool. The tool features multiple options to help get DX NetOps NFA or Application Delivery Analysis secured. You can download the ApplyHTTPS.zip file from this document. Please review the options below and see the additional notes for troubleshooting.

Latest Version: ApplyHTTPS 24.3.3 (November 22, 2024)

**For NFA versions 23.3.2+ you will have to provide a friendly DNS name / FQDN when prompted. This name you provide MUST be found in the certificate's Common Name or Subject Alternative Name**

**We now have a parameters.config file included which we can custom set the Default Web Site name, IIS, OData, Jetty SSO ports, and a SOAP HTTPS option if you don't use the defaults.

**You can now build certificate keystores and certificate requests (to be signed) with SAN's right from this tool with options 5 and 6.

**No longer supports NFA 9.3.3 to 9.3.7.

**For ADA versions 11.2+ you will have to provide a password to access the super database. The tool assumes the database user is "super".**

If you need help generating a signed certificate, please see: NFA HTTPS: How to generate and apply signed certificates

 

Environment

Network Flow Analysis 9.3.8 - 24.3.2

Application Delivery Analysis 11.0 to 11.2.1.27

 

Cause

To minimize the time it takes to manually set up SSL for IIS, Jetty SSO, Jetty RIB, OData, and SOAP Internal Services. (OData for NFA 21.2.4+ / SOAP for NFA 23.3.2+)

Resolution

• This tool needs to be downloaded and extracted to the NFA Console Server only.
• All files contained in the zip file must be extracted to the same place.

ApplyHTTPS.exe must be ran AS AN ADMINISTRATOR.


Using the tool:

1. Option 1: Apply HTTPS. This option was written to help users apply HTTPS to a server which has never seen an HTTPS setup before as well as an NFA server which has just been upgraded and had it's HTTPS settings overwritten.

1. "Use a PFX file."
   
   This option will ask you to specify the direct path to a .PFX /.P12 PKCS12 format file keystore that contains a private key and signed certificate. It will also prompt for the passphrase of the keystore file. From there the tool will import the private key and certificate(s) into the Windows personal certificate store along with the root or intermediate certificates if found in the file. It will then setup the IIS Web Server to use the certificate. It will also setup the Jetty web server used for Single Sign On and RIB. For 21.2.4+, this will enable OData SSL as long as RIB SSL is turned on. This option supports signed or self-signed certificates.
   
   
2. "Use an IIS installed certificate"
   
   This option is useful if you already have a certificate (with an exportable private key) available in one of the two build in Windows Certificate Stores. You can select from either the Personal or WebHosting Store to search for your certificate.
   
   In the example above we are looking at the the Windows Personal Store. There are 3 certificates to choose from. In order to ensure you are choosing the right certificate we believe it is best to check and confirm the subject, thumbprint, and expiration date on the certificate you wish to use. Once you enter a certificate number, the tool will set up the IIS web server to use this certificate. It will also setup the Jetty web server used for Single Sign On and RIB. For 21.2.4+, this will enable OData SSL as long as RIB SSL is turned on. This option supports signed / self-signed certificates. It requires the private key attached to the certificate that you choose to be marked as exportable. If it is not exportable, it will throw and error. Contact your Certificate Authority to get the private key file or complete keystore to continue the process. If the self-signed cert is not exportable, you can just create a new one. This option will also import the certificate chain into the Java CACERTS truststore. The same description can be applied to the Web Hosting Store.
3. "Create and use a self-signed certificate"
   
   This option does exactly what you would think it does. It creates a basic self-signed certificate by creating a private key and single self-signed certificate in the windows personal certificate store. It then exports the keystore and self-signed certificate so that it could be used with SSO, RIB, OData and the Java CACERTS truststore just like the above processes.
   
   
4. "Post-Upgrade / Automatic re-apply certificates"
   
   
   
   This option is great for post-upgrade reapplies. The tool will look for the certificate that is bound to port 443 (or setting in the newly included paramters.config file) in IIS (which does not get overwritten during upgrades), and export the keystore and use the certificate to setup SSO and RIB just like above. 

What does the tool actually do after you select your option to apply HTTPS?

Above is an example of choosing a self-signed single certificate from the Windows Personal Store. I will break down what each step does into more detail.

1.  Ensures that the Default Web Site in IIS is using Port 443 and the certificate of your choosing.
2.  Creates a keystore and truststore for the Jetty SSO and Jetty RIB web servers with an obfuscated password.
3.  Sets up the Jetty SSO and Jetty RIB configuration files for SSL based on the version / options chosen.
4.  Breaks down the certificate chain into separate certificates to be imported into the Java CACERTS truststore.
5.  Sets the proper database / SsoConfig tool settings for SSL to work for SSO.
6.  Detects if you had RIB SSL setup or not.
   1. If yes, it will properly reconfigure the config files.
   2. If no, it sets the RIB config files up for SSL without turning it on. The NFA self-signed or certificate authority root and intermediate certificates will need to be manually imported into the NetOps Portal's CACERTS truststore along with the NFA data source change (set 'Web Site' AND 'Data Source' to https / 443 in the NetOps Portal Administration > Data Sources page).
7.  Restarts the necessary web servers based on the version, options chosen.

Other options of the tool:

Option 2: Simply set NFA to use the default HTTP configurations for IIS, Jetty SSO, OData, and Jetty RIB servers.

Above is an example of choosing option 2 "HTTP Mode". I will break down what each step does into more detail.

1.  Ensures that the Default Web Site in IIS is using Port 80 (or whatever is set in the parameters file) with no certificate.
2.  Sets up the Jetty SSO, Jetty RIB, OData configuration files for default HTTP settings based on the version / options chosen.
3.  Sets the proper database / SsoConfig tool settings for default HTTP to work for SSO.
4.  Detects Jetty RIB to be used over the default HTTP scheme / port.
5.  Restarts the necessary web servers based on the version, options chosen.

Option 3: Import certs for LDAPS / SMTPS / or a Cert Authority cert update only.

This option can be used for importing new certificates into the Java CACERTS truststore. This can be used if you are updating a Certificate Authority certificate for LDAPS or SMTPS. This could also be helpful if you are trying to renew a Certificate Authority certificate with Java CACERTS for Jetty SSO or Jetty RIB. This option will also import it into the Windows Trust root certificate truststore. 

Option 4: Set RIB/OData HTTPS Flag

This option simply sets a flag for the next time you run ApplyHTTPS option (1). This will set up RIB and OData HTTPS if it was not set up prior. This option is not needed if RIB/OData is already using HTTPS. Please make sure the root and intermediate certificates that are used for the NFA Server are imported into the Java CACERTS truststore on the NetOps Portal. You will have to make sure both the web site and data source are set for HTTPS/443 in NetOps Portal > Administration > Data Sources > Data Sources > Edit NFA.

Option 5 : Create a new signed certificate request and keystore

This new option is here to help make it easier to create new signed certificate requests. The tool will create an installdir\NFA\certs\ApplyHTTPS folder and drop a keystore file and CSR file when you complete the required steps. You can now provide your csr file to your certificate authority to be signed. Once they provide you a file back you can use option 6 to complete the keystore creation.

Option 6: Complete a signed certificate request

Use this option to import the signed certificate your certificate authority provided after using Option 5. The accepted formations are DER / Base 64 encoded PEM/CER/CRT files. Once the certificate is imported into your keystore file, you can use your pfx keystore file to apply to NFA. Use HTTPS option 1 (PFX option) or import to IIS and use the option 2 (IIS Import option).

Parameters.config:

If you use different ports for the IIS HTTP/HTTPS web site, SSO HTTPS, or OData you can set those defaults here. Please keep in mind, if you download a new version of this tool, you will have to update these parameters again. Another option is to disable SOAP HTTPS. We don't recommend that as it would keep port 80 active on the server for internal traffic. 

Additional Information

• ALWAYS run the file as an administrator. Even if you are logged on as an administrator.
• The executable is not signed and may be flagged by a virus scanner. It is safe to get an exception for this if needed.
• If the file does not launch, try right clicking the ApplyHTTPS.exe file and go to properties. See if the file is being blocked. If so, unblock it. 
• This tool was created by Justin Signa from DX NetOps Support Team. Please contact Broadcom support if you have an issue with this tool.
• If the file won't download because a "virus" has been detected, check Windows Defender right after downloading and select the action to "allow on device" then re-download it.
• OpenSSL is no longer included nor required.
• Option 5 and 6 will always create your certificate files in installdir\NFA\certs\ApplyHTTPS.
• For NFA versions 23.3.2+ you will have to provide a friendly DNS name / FQDN. This name you provide MUST be found in the certificate's Common Name or Subject Alternative Name. If this is not set properly, the ASP pages will no load properly.
• We will now store the private key and signed certificate in a file called KEYSTORE as opposed to <filename>.pfx/.p12