Remote Data Collectors Without DNS

Occasionally, data collector appliances need to be deployed in environments where DNS resolution is not available. In particular, if a data collector appliance cannot resolve the fully-qualified domain name (FQDN) of the superior application server appliances, they will be unable to join the FMOS ecosystem if the default configuration is used.

The Data Collector communicates with Security Manager using HTTPS. To ensure the communication channel is secure from eavesdroppers and man-in-the-middle attacks, the Data Collector enforces strict validation of the certificate presented by the Security Manager server when establishing the TLS connection. One of the required validation rules is that the name listed on the certificate, either in the certificate subject or the subject alternative name, matches the name specified when the appliance first joins the ecosystem. By default, FMOS generates a certificate for Security Manager that only includes the FQDN of the server. Thus, the FQDN must also be specified when joining the ecosystem. If the FQDN cannot be resolved, then that name cannot be used, so certificate validation will never succeed.

Step 1: Generate a New Certificate

Certificates can include IPv4 and IPv6 addresses in their subject alternative name, but FMOS does not do this by default. In order for data collectors or other clients to use an IP address to contact Security Manager, the server certificate will need to be replaced with one that includes the IP address(es) of the appliance. The fmos pki gen-csr command can be used to create a new Certificate Signing Request that includes the IP addresses of the appliance on which it was run.

To generate a new certificate, complete the following steps.

  1. Log on to the application server machine.
  2. At the prompt enter: fmos pki gen-csr --ip-address -K server.key server.csr. IP address of the machine.

    This will generate a new RSA key pair and store it in server.key. It will then create a new CSR that includes the FQDN of the appliance as well as all of its IP addresses. IPv4 and IPv6 addresses will be included, except for IPv6 link-local addresses.

    The command will prompt for an export passphrase. If supplied, this will be used to encrypt the private key file in server.key for safe keeping. Encrypting the key is optional, and can be skipped by pressing Enter at the prompts.

Step 2: Sign the Certificate

To convert the new CSR into a certificate that can be used by Security Manager, it must be signed by a certificate authority (CA). Which CA signs the certificate will depend on the security policy of the organization.

  • Organization/Corporate CA—An internal certificate authority operated by the customer’s organization. Most organizations operate a CA, and deploy configuration to end user devices to ensure certificates it signs are trusted, so this should be the preferred option if possible.
  • Public CA—Some organizations require that their certificates be signed by one of the public certificate authorities such as Thawte or VeriSign. It is important to verify that the CA will sign a certificate that includes an IP address, as many of them will only sign certificates for FQDNs.
  • FMOS Ecosystem CA—The CA operated automatically by FMOS.

Step 3: Use an External CA

Every CA has a different method for submitting a CSR and receiving a signed certificate. If your organization has an internal CA, the administrator should have documentation specifying how to use it. For public CAs, the process can normally be found on their websites.

Most public CAs use an intermediate CA certificate to sign certificates, as do some internal CAs. In this case, be sure to obtain the certificate chain file that includes any necessary intermediate CA certificates.

Step 3: Use the FMOS CA

If you do not have an internal CA, the fmos ca command can be used (on the server that holds the Certificate Authority role) to sign the CSR and issue a new certificate.

To use the FMOS CA, complete the following steps.

  1. Log on to the CA machine.
  2. Copy the CSR (server.csr) file from the application server to the CA machine, if they are not the same machine.

  3. At the prompt, enter fmos ca sign server.csr server.cer, and then fmos ca export-ca-cert --ca server server-chain.crt.

    This will produce a file named server.cer that contains the signed server certificate. Additionally, it will create server-chain.crt, which contains the intermediate CA certificate that signed the server certificate.

Step 4: Verify the Certificate

After receiving a signed certificate from the CA, the openssl x509 command can be used to verify that it does in fact contain the IP address of the Security Manager server.

  • At the prompt enter: openssl x509 -in server.cer -noout -text -certopt no_pubkey,no_sigdump

    If the certificate is correct, it will have a section labeled X509v3 Subject Alternative Name with one or more IP address entries below it.

Step 5: Import the New Certificate

After verifying that the new certificate is correct, it can be imported using the fmos pki import-server-cert command.

To import the new certificate, complete the following steps.

  1. Log on to the application server machine.
  2. Copy the newly-signed certificate, as well as the intermediate CA chain file, if any, to the application server appliance, if necessary.
  3. At the prompt enter: fmos pki import-server-cert server.cer server.key --chain server-chain.crt

    This will import the new server certificate and make adjustments to the system configuration to use it. If the private key file is encrypted, the command will prompt for the passphrase before making any changes.

Step 6: Join the Ecosystem

After the new certificate has been imported onto the application server, data collectors can now be added to the ecosystem by specifying its IP address as their superior server.

To join the ecosystem, complete the following steps.

  • At the prompt enter: fmos ecosystem join <IPv4 or IPv6 IP address>

    The command will prompt for initial manual verification as usual, and will proceed in the same manner as if the FQDN had been used.