Configuring the HTTPS certificate for Xona

1. Purpose

Use this guide to install a trusted HTTPS server certificate on a XONA Critical System Gateway (CSG) or XONA Central Manager (XCM).

A trusted certificate helps browsers and other clients confirm the identity of the XONA appliance. It is also important for browser functions that require a secure HTTPS connection, such as WebAuthn.

This guide uses the certificate requirements in the public XONA documentation. Confirm the requirements for your installed XONA version before you start.

2. XONA certificate requirements

Prepare the server certificate and private key before you open the XONA certificate page.

The files must meet these requirements:

The certificate must use PEM encoding.
The private key must use PEM encoding.
The private key must not have a passphrase.
The certificate and private key must be a matching pair.
PKCS#12 files, such as .pfx and .p12 files, cannot be uploaded directly.
An RSA key must be either least 3072 or 4096 bits when FIPS mode is enabled.
An RSA 2048-bit key is supported only when FIPS mode is disabled.
XONA also supports ECDSA private keys of any size.
The server certificate should include the intermediate CA certificates that form its signing chain.

PEM files contain Base64-encoded data between header and footer lines. File extensions such as .pem, .crt, and .key do not determine the format. The content of the file determines the format.

The current XONA documentation recommends a server certificate bundle that includes the signing chain. This configuration improves compatibility with clients that do not automatically download intermediate CA certificates.

Important: Use the Server Certificate function for the HTTPS certificate of the appliance. Do not use the Trusted CA Certificates function for this purpose. Trusted CA certificates are used to validate outbound TLS connections, such as connections for HA, log forwarding, and email alerts.

3. Plan the certificate names

Determine how users will access each appliance.

Use a fully qualified domain name, such as:

csg1.xona.example.com

Create a DNS record that maps this name to the XONA appliance.

The certificate Subject Alternative Name, or SAN, must contain every DNS name that users or applications will use to connect to the appliance. Modern TLS clients use the SAN when they validate the server name.

For example:

DNS:csg1.xona.example.com

Do not create a certificate for one name and access the appliance with a different name or an IP address. This configuration causes a certificate name error unless the different name or IP address is also in the SAN.

4. Select a certificate design

4.1 One certificate for each appliance

This is the preferred design.

Create a separate certificate and private key for each CSG and XCM. This design limits the effect of a private-key compromise.

Example:

csg1.xona.example.com
csg2.xona.example.com
xcm.xona.example.com

Each appliance gets a different certificate and private key.

4.2 SAN certificate

A SAN certificate contains two or more DNS names.

A SAN certificate can be useful for:

The primary and secondary CSGs in an HA pair.
A small group of XONA appliances.
An environment in which certificate deployment must be simplified.

Example SAN list:

DNS:csg1.xona.example.com
DNS:csg2.xona.example.com
DNS:xcm.xona.example.com

You must install the same private key on every appliance that uses the SAN certificate. A compromise of one appliance can therefore affect all appliances that use that key.

4.3 Wildcard certificate

A wildcard certificate can cover multiple appliances under one DNS domain.

Example:

*.xona.example.com

This wildcard can cover:

csg1.xona.example.com
csg2.xona.example.com
xcm.xona.example.com

It does not normally cover:

xona.example.com
csg1.site1.xona.example.com

A wildcard certificate simplifies large deployments, but it also requires the same private key on many appliances. Use it only when your security policy permits shared wildcard keys. The CA/Browser Forum defines a wildcard certificate as a certificate with a wildcard domain name in its SAN.

5. Obtain a CA-signed certificate

A certificate signed by an approved internal or public certificate authority is the preferred option.

Work with your PKI or certificate team before you create the certificate signing request, or CSR. The team can specify:

The required certificate template.
The approved key algorithm and key size.
Required subject fields.
Required SAN entries.
Certificate validity limits.
Private-key storage requirements.

For Microsoft Active Directory Certificate Services, the required template is frequently named Web Server. The issued certificate must permit Server Authentication.

Create the CSR outside the XONA appliance. Keep the private key on a secure system until you upload it to XONA.

6. Create a CSR

6.1 Create a CSR for Active Directory Certificate Services (AD CS)

Many organizations rely on internal certificate authorities based upon Microsoft's Active Directory Certificate Services (AD CS). In these environments, it is best to work with the PKI administrators to have your certificate created. Here is the general guidance:

Use the Web Server CSR template.
Ensure the certificate and private key are provided as a PFX file.
The PFX file must be generated with the private key marked as exportable..
Convert the PFX certificate to a PEM certificate and a decrypted PEM key using OpenSSL (see 7. Convert a PFX or P12 file).

6.2 Create a CSR with OpenSSL

If you are not relying on Active Directory Certificate Services for an internal PKI, then it these examples using OpenSSL are recommended. The following examples create:

A 3072-bit RSA private key.
An unencrypted PEM private-key file.
A CSR for one XONA appliance.
A DNS SAN that matches the appliance FQDN.

If Using OpenSSL 3.x

openssl req -new -newkey rsa:3072 -noenc -keyout csg1.xona.example.com.key -out csg1.xona.example.com.csr -subj "/C=US/ST=New York/L=New York/O=Example Corporation/OU=Operations/CN=csg1.xona.example.com" -addext "subjectAltName=DNS:csg1.xona.example.com"

If Using OpenSSL 1.1.1

Use the same command, but replace -noenc with -nodes:

openssl req -new -newkey rsa:3072 -nodes -keyout csg1.xona.example.com.key -out csg1.xona.example.com.csr -subj "/C=US/ST=New York/L=New York/O=Example Corporation/OU=Operations/CN=csg1.xona.example.com" -addext "subjectAltName=DNS:csg1.xona.example.com"

OpenSSL 3 uses -noenc for an unencrypted output key. The older -nodes option is deprecated in OpenSSL 3 but is used by earlier versions.

Store the private key in a restricted folder. Do not send it by email or attach it to a certificate request.

Create a CSR with multiple SAN entries

Use a comma-separated SAN list:

openssl req -new -newkey rsa:3072 -noenc -keyout xona-appliances.key -out xona-appliances.csr -subj "/C=US/ST=New York/L=New York/O=Example Corporation/OU=Operations/CN=csg1.xona.example.com" -addext "subjectAltName=DNS:csg1.xona.example.com,DNS:csg2.xona.example.com,DNS:xcm.xona.example.com"

Include the Common Name in the SAN list.

Your CA can ignore or replace extensions in the CSR. Confirm the final SAN list after the CA issues the certificate.

7. Convert a PFX or P12 file

Windows certificate systems frequently provide the certificate, private key, and CA chain in one .pfx or .p12 file.

The private key must be exportable. If it is not exportable, request a new certificate or generate the CSR on a system where you control the private key.

Run the conversion in a secure working folder. After conversion, you should see the following files:

original.pfx or original.p12
server.key
server.crt

7.1 Extract an unencrypted private key

For OpenSSL 3.x:

openssl pkcs12 -in original.pfx -nocerts -noenc -out server.key

For OpenSSL 1.1.1:

openssl pkcs12 -in original.pfx -nocerts -nodes -out server.key

OpenSSL writes PKCS#12 output in PEM format. The -nocerts option extracts only the private key. The -noenc option prevents encryption of the output key.

7.2 Extract the server certificate

openssl pkcs12 -in original.pfx -clcerts -nokeys -out server.crt

7.3 Extract the CA chain

openssl pkcs12 -in original.pfx -cacerts -nokeys -out ca-chain.crt

The PFX file might not contain the complete CA chain. Obtain missing intermediate certificates from your CA.

7.4 (Optional) Create the server certificate bundle

Follow your CA instructions about whether to include the root CA certificate. In most environments, client systems already have the root CA certificate.

Place the server certificate into the secure working folder first. Place the intermediate CA certificates after it.

On Linux or macOS:

cat server.crt ca-chain.crt > server-chain.crt

In Windows Command Prompt:

type server.crt ca-chain.crt > server-chain.crt

8. Remove a passphrase from an existing private key

Use this command if you already have an encrypted PEM private key:

openssl pkey -in encrypted.key -out server.key

OpenSSL asks for the current passphrase. It then writes an unencrypted PEM private key.

The pkey command supports more private-key types than the older rsa command. OpenSSL documents it as the general private-key processing command.

Protect the unencrypted output file. Delete temporary private-key files when you no longer need them.

9. Validate the files

Validate the certificate and key before you upload them.

9.1 Review the certificate

openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName

Confirm these items:

The subject is correct.
The issuer is the expected CA.
The certificate is currently valid.
The SAN contains every required FQDN.

9.2 Validate the private key

openssl pkey -in server.key -check -noout

The command must complete without a key error.

If OpenSSL asks for a private-key passphrase, the key is still encrypted. Remove the passphrase before you upload the key.

9.3 Confirm that the certificate and key match

Calculate a hash of the public key in the certificate:

openssl x509 -in server.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Calculate a hash of the public key in the private key:

openssl pkey -in server.key -pubout -outform DER | openssl dgst -sha256

The two SHA-256 values must be identical.

10. Upload the certificate to XONA

Sign in to the XONA appliance as an administrator.
Go to Settings.
Go to Security.
Select Certificates.
Select the function to upload a server certificate.
Select the certificate bundle, such as server-chain.crt.
Select the unencrypted private key, such as server.key.
Upload or save the files.
Reconnect to the appliance with its FQDN.
Confirm that the browser trusts the certificate.

XONA accepts the custom server certificate and matching key in PEM format. It does not accept a PFX or P12 file directly.

Test all clients that connect to the appliance, including:

Supported browsers.
Command-line clients.
Monitoring systems.
API integrations.
HA peers, when applicable.

11. Use a self-signed certificate

Use a CA-signed certificate when possible.

Use a self-signed certificate only in a controlled environment where you can install the certificate in the trust store of every client.

XONA can reset the server certificate to a new self-signed certificate. The generated certificate uses the appliance hostname as a DNS SAN. This option can help with WebAuthn in environments that do not have a certificate authority. Resetting a CA-signed certificate can cause clients that require certificate validation to stop working.

You can also create a custom self-signed certificate with OpenSSL.

Self-signed certificate for one appliance

openssl req -x509 -newkey rsa:3072 -sha256 -noenc -keyout csg1.xona.example.com.key -out csg1.xona.example.com.crt -days 365 -subj "/C=US/ST=New York/L=New York/O=Example Corporation/OU=Operations/CN=csg1.xona.example.com" -addext "subjectAltName=DNS:csg1.xona.example.com" -addext "extendedKeyUsage=serverAuth"

For OpenSSL 1.1.1, replace -noenc with -nodes.

Install the self-signed certificate in the trusted certificate store of each client workstation. The client must:

Trust the certificate.
Use the FQDN in the certificate SAN.
Resolve the FQDN to the correct XONA appliance.

A local hosts-file entry can provide name resolution when DNS is not available. DNS is easier to manage for large deployments.

Self-signed SAN certificate for multiple appliances

openssl req -x509 -newkey rsa:3072 -sha256 -noenc -keyout xona-appliances.key -out xona-appliances.crt -days 365 -subj "/C=US/ST=New York/L=New York/O=Example Corporation/OU=Operations/CN=csg1.xona.example.com" -addext "subjectAltName=DNS:csg1.xona.example.com,DNS:csg2.xona.example.com,DNS:xcm.xona.example.com" -addext "extendedKeyUsage=serverAuth"

This method uses the same private key on all listed appliances. Use it only when the reduced management effort is more important than private-key isolation.

12. Troubleshooting

XONA rejects the certificate file

Confirm that the file is PEM encoded.

A PEM certificate must contain:

-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

Remove PKCS#12 bag attributes or other text if the upload parser rejects the file. Keep the PEM certificate blocks.

XONA rejects the private key

Confirm these items:

The key uses PEM encoding.
The key does not have a passphrase.
The key type is supported.
If applicable, the RSA key size meets the FIPS-mode requirement.
The key matches the server certificate.

An unencrypted private key normally contains one of these headers:

-----BEGIN PRIVATE KEY-----

or:

-----BEGIN RSA PRIVATE KEY-----

The browser reports a name mismatch

Connect with a DNS name that is in the certificate SAN.

Add all required FQDNs to the SAN when you request the certificate. Add an IP SAN only when users must connect by IP address and your CA permits it.

The browser reports an incomplete certificate chain

Upload a certificate bundle that contains:

The server certificate.
The issuing intermediate CA certificate.
Any additional intermediate CA certificates.

Do not place an intermediate certificate before the server certificate.

The certificate works on one computer but not another

The second computer might not trust the issuing CA.

For a private CA or self-signed certificate, install the required root certificate in the client trust store.

An RSA 2048-bit certificate fails in FIPS mode

Request a certificate with an RSA key of at least 3072 bits, or use an approved ECDSA key. XONA documents RSA 2048 support only for non-FIPS operation.

13. Security recommendations

Use a CA-signed certificate when possible.
Use a separate private key for each appliance when possible.
Do not send private keys by email.
Store private keys only in secure folders on your computer.
Delete temporary unencrypted private-key files after installation.
Keep a secure backup if your certificate-recovery process requires one.
Record the certificate expiration date and schedule a calendar event as a reminder for certificate renewal.
Follow your organization’s PKI and private-key handling policies.
Limit SAN and wildcard certificates to the systems that require them.
Replace all certificates that use a shared key if that key is compromised.

Configuring the HTTPS certificate for Xona

Guidance on configuring how to install a trusted HTTPS certificate on Xona.

1. Purpose

2. XONA certificate requirements

3. Plan the certificate names

4. Select a certificate design

4.1 One certificate for each appliance

4.2 SAN certificate

4.3 Wildcard certificate

5. Obtain a CA-signed certificate

6. Create a CSR

6.1 Create a CSR for Active Directory Certificate Services (AD CS)

6.2 Create a CSR with OpenSSL

If Using OpenSSL 3.x

If Using OpenSSL 1.1.1

Create a CSR with multiple SAN entries

7. Convert a PFX or P12 file

7.1 Extract an unencrypted private key

7.2 Extract the server certificate

7.3 Extract the CA chain

7.4 (Optional) Create the server certificate bundle

8. Remove a passphrase from an existing private key

9. Validate the files

9.1 Review the certificate

9.2 Validate the private key

9.3 Confirm that the certificate and key match

10. Upload the certificate to XONA

11. Use a self-signed certificate

Self-signed certificate for one appliance

Self-signed SAN certificate for multiple appliances

12. Troubleshooting

XONA rejects the certificate file

XONA rejects the private key

The browser reports a name mismatch

The browser reports an incomplete certificate chain

The certificate works on one computer but not another

An RSA 2048-bit certificate fails in FIPS mode

13. Security recommendations