Share This:

The Discovery Outpost is one of the major new features of the Discovery 12 (20.02) release that provides a lightweight Windows-based component that can replace proxies and consolidation scanner appliances. It has its own HTTPS-based UI, and after installation generates its own self-signed certificates - hence your browser will have to be told to trust it, as there is no chain of trust to a known CA. The certificate will look something like this in your browser:

Def Cert.png

The auto-generated key and certificate files are stored in C:\Program Files\BMC Software\Discovery Outpost\etc\https (unless you have changed the install directory from the default) as

  • server.key
  • server.crt

You will find it has a 4k RSA public key, with 10 year lifetime:

cert1.png

It is standard practice in an organisation, at least for production systems, to mandate the use of certificates that are signed by a known and trusted in-house CA. Perhaps you want to reduce the certificate lifetime; this is certainly the trend for Internet-facing certificates.

 

So, is there an easy way to generate your own Outpost keys and certificates, like you can for the appliance? Alas no. The documentation mentions how you can, but the files have to be copied manually (and bounce the Outpost service). You might notice that the server.key file is encrypted (PKCS#8 standard):

so the obvious question is with what password is this encrypted? The answer is that it is the Outposts ID, that can be found in the Discovery Outpost\etc\machine.uuid file, or the tw_svc_outpost.log:

I don't know if there is a native way on Windows to process these PEM-format files, so I use openssl commands on Linux:

Here you can see it asks for the password, to which I entered the Outpost ID. You don't *have* to encrypt the key - the service will read a non-encrypted key, that looks like:

Moreover, I maintain that encrypting the key here is futile and can lead to a false sense of security. By design, the Outpost has to know how to decrypt at startup and as we have seen, that information is held in a file. It would only make sense if user interaction was required, like during Apache Websever startup or a Discovery passphrase-protected-vault. I recommend you consider the Windows OS as the security boundary to the HTTPS key.

 

I expect you woudl request your CA to generate a key/certificate pair; they will need to know the X.509 CN (Common Name) - which will be the DNS name the browser would use to connect to the Outpost. If for some reason you want to generate your own key and CSR to send to your CA you can, using any openssl installation.

 

This is what I used to generate the (4 k bit) key:

 

[nicsmith@npgs-fedora int2]$ openssl genrsa -out private/clm-tlv-uch418.bmc.com.pem 4096

Generating RSA private key, 4096 bit long modulus (2 primes)

......++++

....................................................................................................++++

e is 65537 (0x010001)

[nicsmith@npgs-fedora int2]$ chmod 400 private/clm-tlv-uch418.bmc.com.pem

 

where the clm-tlv-uch418.bmc.com.pem file gets renamed to server.key at the Outpost.

 

This is what I used to generate a CSR:

 

[nicsmith@npgs-fedora int2]$ openssl req -config openssl.conf -key private/clm-tlv-uch418.bmc.com.pem -new -sha256 -out csr/clm-tlv-uch418.bmc.com.csr.pem

Enter pass phrase for private/clm-tlv-uch418.bmc.com.pem:

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [GB]:

State or Province Name [England]:

Locality Name [London]:

Organization Name [BMC Software Ltd]:

Organizational Unit Name [Discovery Support Certification Authority]:

Common Name []:clm-tlv-uch418.bmc.com

Email Address [nick_smith@bmc.com]:

[nicsmith@npgs-fedora int2]$

 

I have my own Root and Intermediate CAs setup, with their certificates trusted by my browser, so I could sign this generated CSR and generate my own server.pem file.

 

Finally, then, you will have a nice HTTPS connection, using a certificate to a browser-trusted CA. This is how it looks for me, in Firefox:

 

If something goes wrong, and SSL library won't initialise, you'll probably get something like this dumped into the outpost.out file:

This happened to me when I initially tried to use an encrypted key with the "-aes256" option to the "openssl genrsa" command. That resulted in this format:

which the Outpost didn't like. If you really feel you want to have an encrypted key, despite my earlier opinions, an acceptable PKCS#8 encrypted file can be generated by:

  • first generate an unencrypted key file
  • then encrypt like this:  openssl pkcs8 -topk8 -in server-unencrypted.key -out server-encrypted.key

 

See here for an old post with some other useful openssl commands.