As documented Relay and Server diagnostics , after enabling the following Relay Diagnostics settings on a v11.0.3 Relay, the relays’ listener on 52311 routes an inbound HTTP to HTTPS.
_BESRelay_Diagnostics_Enable
_BESRelay_Diagnostics_Password
The SSL certificate the Relay uses is self signed. Is there a way to replace this with a signed certificate?
The certificate is issued by the BESRootServer and chained up to the BigFix Root Certificate Authority. This CA is generally not trusted publicly, it’s only intended to be accessed by BigFix clients. The root of the trust is established via the masthead file.
The Relay and Client certificates have often been an issue for network vulnerability scanners. We do now provide a way to export our CA Root Certificate so you can import it in your scanners as a trusted root authority, and avoid the untrusted/self-signed messages from your scanner.
On the BES Root Server, the BESAdmin Tool can now export the CA certificates. See the announcement at BigFix 11.0 Patch 3 is now available!
Added BESAdmin command to return the BigFix certificate bundle!
With the getcertificatebundle BESAdmin command, you can export the complete BigFix certificate bundle. In the bundle, there are all the certificates for all authorized chains in the masthead. This allows the user to provide the full certificate chain to tools or entities that request it for validation. For details, see BESAdmin Windows Command Line and BESAdmin Linux Command Line .
I think there is confusion here. I’m talking about the SSL cert that is on the Relay’s :52311/rd
Relay Diagnostics page ( not the Root and not for client to relay or relay to Root communications).
Is that the same cert you’re talking about that is exportable through the BES Admin?
Yes, that’s what I mean. I’ll go retrieve some details on it, will be back soon.
When we use a browser to open the Relay Diags page, the certificate is untrusted, but if we open it up and view the details we can see it’s issued by ‘Client Certificate Authority’. That ‘Client Certificate Authority’ is actually your BigFix Root Server, and is unique to your deployment (your ‘Client Certificate Authority’ is not the same as my ‘Client Certificate Authority’).
Further, it doesn’t have a ‘Common Name (CN)’. But if we go into the details and check the Subject, we can see it’s actually issued to a Bigfix ComputerID field, not to a hostname:
If we go to the Root Server, we can use BESAdmin to export the certificate chain (including your instance of ‘Client Certificate Authority’) :
C:\BES\Server>BESAdmin.exe /?
C:\BES\Server>mkdir \bes\certs\bes-bundle
C:\BES\Server>.\BESAdmin.exe /getcertificatebundle /bundleCertDir=c:\bes\certs\bes-bundle
C:\BES\Server>dir c:\bes\certs\bes-bundle
Volume in drive C has no label.
Volume Serial Number is C0BC-855F
Directory of c:\bes\certs\bes-bundle
01/14/2025 03:36 PM <DIR> .
01/14/2025 03:36 PM <DIR> ..
01/14/2025 03:36 PM 212,818 bundle.pem
1 File(s) 212,818 bytes
If we then use OpenSSL to verify the Relay using that bundle, it is successful:
openssl s_client -showcerts -connect osd.local:52311 -CAfile bundle.pem
C:\BES\certs\bes-bundle>openssl s_client -showcerts -connect osd.local:52311 -CAfile bundle.pem
CONNECTED(000001CC)
depth=4 C = US, ST = California, L = Emeryville, O = HCLTech, OU = Site Authorization, CN = Root Certificate, emailAddress = bigfix-security-team@hcl.com
verify return:1
depth=3 C = US, ST = California, O = HCLTech, OU = Site Authorization, CN = ActionSite Registrar:Secure License, emailAddress = bigfix-security-team@hcl.com
verify return:1
depth=2 C = US, <SNIP>
verify return:1
depth=1 CN = Client Certificate Authority
verify return:1
depth=0 name = ComputerID:11635830
verify return:1
---
Certificate chain
0 s:name = ComputerID:11635830
i:CN = Client Certificate Authority
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Jan 14 21:47:44 2025 GMT; NotAfter: Feb 16 21:47:44 2026 GMT
-----BEGIN CERTIFICATE-----
MIIDIjCCAgqgAwIBAgIEALGMdjANBgkqhkiG9w0BAQwFADAnMSUwIwYDVQQDExxD<SNIP>
-----END CERTIFICATE-----
1 s:CN = Client Certificate Authority
i:C = US, CN =<SNIP>
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Aug 11 16:23:22 2023 GMT; NotAfter: Aug 8 16:23:22 2033 GMT
-----BEGIN CERTIFICATE-----
MIIFVjCCAz6gAwIBAgIEv1x/gzANBgkqhkiG9w0BAQwFADCCAV8xCzAJBgNVBAYT<SNIP>
-----END CERTIFICATE-----
---
Server certificate
subject=name = ComputerID:11635830
issuer=CN = Client Certificate Authority
---
No client certificate CA names sent
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2804 bytes and written 425 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
That output shows that, given the bundle.pem exported by BESAdmin, OpenSSL can trust/validate the Relay certificate.
Getting Windows/Browser to trust the connection is more complicated. As far as I know, the Windows Certificate Manager client (the MSC graphical interface, or certutil.exe) don’t handle multiple certificates in a single PEM file. So I’ve had to extract each of those certificates to a separate file, numbered 1.pem through 6.pem in my case. Then I use certutil to import each of them into the ‘Trusted Root Authorities’ certificate store:
certutil –addstore -enterprise –f "Root" c:\bes\certs\bes-bundle\1.pem
certutil –addstore -enterprise –f "Root" c:\bes\certs\bes-bundle\2.pem
… and so on.
Then, restarting Chrome and browsing to the RD page, I get… another error!
This is different though - it’s not longer an ‘Untrusted Issuer’, now it’s a ‘COMMON_NAME_INVALID’ - which means there is no Hostname on the certificate matching the Relay hostname that I’m trying to browser. But I knew that, the certificate was issued to a BES ComputerID, and has no Subject or SubjectAltName entries with DNS hostnames in it.
And…according to Client certificate , it should have a SubjectAltName…but that starts in BigFix 11.0.3, and I see I never upgraded this Relay from 11.0.0, so I’ll run that upgrade and get back to you again.
thanks for all the investigation. Yes, I’m curious what your 11.0.3 shows if you do get that upgraded. This all stems from me having a python script monitor hitting the relay (masthead URL) to ensure a response and I need to have a trusted HTTPS connection.
thanks
After upgrading my relay & client to 11.0.3, it enrolled a new certificate that included a Subject Alternative Name, as expected. The browser can trust it now, as long as I connect using a hostname that matches the certificate. That can be tricky if you’re using DNS aliases.
I’m not sure whether we have client settings yet to enroll additional names or domain names besides whatever the client detects for itself. I’ll check internally to see whether we have anything potentially undocumented, if you think you may need to enroll for specific names.
Yes, I would need an alternative name for it to work for me if possible\
@JasonWalker , any luck with finding a way for an Alternative Name?
Negative, it doesn’t look like there is a way to customize the certificate request; the client will also request a certificate with a SAN matching its own fully-qualified hostname, as reported by the operating system
