Configuring the HTTPS certificate for 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

6.2.1 Minimum Required OpenSSL CSR

6.2.2 Recommended OpenSSL CSR

6.2.3 OpenSSL CSR for multiple DNS names and IPs

6.2.4 Validate the CSR using OpenSSL

6.2.5 Validate the issued certificate using OpenSSL

6.2.6 Key Encipherment compatibility option

7. Preparing the issued certificate

7.1 Preparation using a PKCS#12 fiile

7.1.1 Extract an unencrypted private key from a PKCS#12 file

7.1.2 Extract the server certificate

7.1.3 Extract the CA chain

7.2 Preparation using a base64-encoded key file

7.3 Create the server certificate bundle

8. Validate the files

8.1 Review the certificate

8.2 Validate the private key

8.3 Confirm that the certificate and key match

9. Use a self-signed certificate

9.1 Automatically generating a self-signed certificate

9.2 Using OpenSSL to generate a self-signed certificate

9.3 Self-signed SAN certificate for multiple appliances

10. Upload the certificate to XONA

11. Troubleshooting

12. Security recommendations

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.

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

The CSR contains the public key, the requested subject name, and optional requested certificate extensions.

The CSR is ready for submission when:

The private key is RSA 3072 bits or larger.
The CSR contains the correct SAN values.
Digital Signing Certificate Key Usage (CKU).
Server Authentication Extended Key Usage (EKU).
The CSR signature verifies successfully.

The CA controls the final certificate. The CA can:

Accept the requested extensions.
Replace the requested extensions.
Add extensions from a certificate template.
Reject extensions that do not comply with CA policy.

Xona does not recommend adding clientAuth, codeSigning, emailProtection, or anyExtendedKeyUsage to the Extended Key Usage attribute.

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

When your Certificate Authority uses Microsoft Active Directory Certificate Services (AD CS), it is recommended to use the Web Server CSR template.

In addition to the requirements listed in 6. Create a CSR, the AD CS CSR template must produce a certificate with:

An exportable private key when the certificate will be exported as a PFX file.
A key size that meets the XONA operating-mode requirement.

The Microsoft template can control the final Certificate Key Usage and Extended Key Usage values. It can ignore values in the CSR. Therefore, selecting the correct template is as important as creating the correct CSR.

6.2 Create a CSR with OpenSSL

The following examples demonstrate how to create a CSR using OpenSSL with the following results:

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

These results align with the requirements listed in 6. Create a CSR, including:

The CSR requests digitalSignature for keyUsage.
The CSR requests serverAuth Extended extendedKeyUsage.

The SAN is required for server-name validation. Do not depend only on the Common Name. Current public TLS certificate requirements require at least one DNS name or IP address in the SAN.

6.2.1 Minimum Required OpenSSL CSR

If Using OpenSSL 3.x

openssl req -new \
 -newkey rsa:3072 \
 -noenc \
 -sha256 \
 -keyout csg1.xona.example.com.key \
 -out csg1.xona.example.com.csr \
 -subj "/CN=csg1.xona.example.com" \
 -addext "subjectAltName=DNS:csg1.xona.example.com" \
 -addext "extendedKeyUsage=serverAuth" \
 -addext "keyUsage=critical,digitalSignature"

If Using OpenSSL 1.1.1, then use the same command as OpenSSL 3.x, but replace -noenc with -nodes:

openssl req -new \
 -newkey rsa:3072 \
 -nodes \
 -sha256 \
 -keyout csg1.xona.example.com.key \
 -out csg1.xona.example.com.csr \
 -subj "/CN=csg1.xona.example.com" \
 -addext "subjectAltName=DNS:csg1.xona.example.com" \
 -addext "extendedKeyUsage=serverAuth" \
 -addext "keyUsage=critical,digitalSignature"

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.

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

6.2.2 Recommended OpenSSL CSR

Use a configuration file for production requests. A configuration file is easier to review and less likely to contain command-line errors.

Create a file named xona-csr.cnf:

[req]
prompt = no
default_md = sha256
distinguished_name = subject
req_extensions = requested_extensions

[subject]
C = US
ST = New York
L = New York
O = Example Corporation
OU = Operations
CN = csg1.xona.example.com

[requested_extensions]
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @subject_alt_names

[subject_alt_names]
DNS.1 = csg1.xona.example.com

Create the CSR with OpenSSL 3.x:

openssl req -new \
   -newkey rsa:3072 \
   -noenc \
   -keyout csg1.xona.example.com.key \
   -out csg1.xona.example.com.csr \
   -config xona-csr.cnf

For OpenSSL 1.1.1, replace -noenc with -nodes.

This request uses the following profile:

Field	Requested value
Public-key algorithm	RSA
RSA key size	3072 bits
CSR signature	SHA-256
Basic Constraints	`CA:FALSE`
Key Usage	`digitalSignature`
Extended Key Usage	`serverAuth`
SAN	Each FQDN used to access the appliance
Common Name	Primary appliance FQDN

basicConstraints=CA:FALSE identifies the certificate as an end-entity certificate and not as a CA certificate. The current public TLS certificate profile requires the final subscriber certificate to have CA set to false.

6.2.3 OpenSSL CSR for multiple DNS names and IPs

If you prefer to use the same certificate for multiple Xona devices, or would like to use multiple DNS names for Xona devices, or wish to have your certificate be valid for specific IP addresses, then add these to the SAN extension.

Example:

[subject_alt_names]
DNS.1 = csg1.xona.example.com
DNS.2 = csg2.xona.example.com
DNS.3 = xcm.xona.example.com
IP.1 = 192.168.1.100
IP.2 = 192.168.127.250

Use only names that users, browsers, APIs, or other clients will use.

Do not add:

Short hostnames that clients will not use.
Old DNS names.
Unrelated appliances.
Wildcard names unless security policy permits a wildcard certificate.

A certificate that contains multiple names normally uses the same private key on all appliances that use that certificate. A compromise of one appliance can affect all appliances that use the shared key.

6.2.4 Validate the CSR using OpenSSL

Inspect the CSR before you send it to the CA:

openssl req \
  -in csg1.xona.example.com.csr \
  -noout \
  -text \
  -verify

Confirm that the output contains:

Requested Extensions:
    X509v3 Basic Constraints: critical
        CA:FALSE
    X509v3 Key Usage: critical
        Digital Signature
    X509v3 Extended Key Usage:
        TLS Web Server Authentication
    X509v3 Subject Alternative Name:
        DNS:csg1.xona.example.com

OpenSSL supports adding subjectAltName, keyUsage, and extendedKeyUsage request extensions with -addext or through a configuration-file extension section.

6.2.5 Validate the issued certificate using OpenSSL

Do not assume that the CA copied the CSR extensions.

Inspect the issued certificate:

openssl x509 \
   -in csg1.xona.example.com.crt \
   -noout \
   -text

Confirm these values:

X509v3 Basic Constraints:
     CA:FALSE  X509v3 Key Usage:
     Digital Signature

X509v3 Extended Key Usage:
     TLS Web Server Authentication

X509v3 Subject Alternative Name:
     DNS:csg1.xona.example.com

Also confirm:

The certificate is currently valid.
The issuer is the expected CA.
The SAN contains all required appliance names.
The certificate does not contain an unintended Client Authentication EKU.
The certificate and private key are a matching pair.
The certificate chain contains the required intermediate CA certificates.

6.2.6 Key Encipherment compatibility option

Some internal CA web-server templates add both of these RSA Key Usage values:

Digital Signature
Key Encipherment

This configuration is compatible with a wider range of older TLS implementations.

Use this CSR value only when your PKI policy or compatibility requirements specify it:

keyUsage = critical,digitalSignature,keyEncipherment

For a current TLS configuration, use this narrower value unless the certificate team specifies otherwise:

keyUsage = critical,digitalSignature

7. Preparing the issued certificate

Follow either 7.1 Preparation using a PKCS#12 fiile or 7.2 Preparation using a base64-encoded key file, then continue to 7.3 Create the server certificate bundle.

7.1 Preparation using a PKCS#12 fiile

Common practice with Microsoft AD CS CAs is to provide the certificate, private key, and CA chain in a PKCS#12-formatted fiile with extension .pfx or .p12. These will need to be extracted individually and converted to base-64 PEM format.

For these files, the private key must be exportable. If it is not exportable, then 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.1 Extract an unencrypted private key from a PKCS#12 file

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.1.2 Extract the server certificate

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

7.1.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.2 Preparation using a base64-encoded key file

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.

7.3 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. Validate the files

Validate the certificate and key before you upload them.

8.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.

8.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.

8.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.

9. 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.

9.1 Automatically generating a self-signed certificate

XONA can reset the server certificate to a new automatically generated self-signed certificate. The generated certificate uses the appliance hostname as DNS SAN and any configured IP addresses as IP SANs. This option can help with WebAuthn in environments that do not have a certificate authority.

Resetting a CA-signed certificate to a self-signed certificat can cause WebAuthn to stop working.

9.2 Using OpenSSL to generate a self-signed certificate

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

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" \
 -addext "keyUsage=critical,digitalSignature"

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.

9.3 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" \
 -addext "keyUsage=critical,digitalSignature"

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.

10. Upload the certificate to XONA

The issued certificate is ready for XONA when:

It contains TLS Web Server Authentication.
It contains the correct DNS SAN values.
It is an end-entity certificate with CA:FALSE.
Its Key Usage permits Digital Signature.
It matches the private key.
It is in PEM format.
The private key is in PEM format and has no passphrase.

To proceed with uploading the certificate to Xona, follow these steps:

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.

Test all clients that connect to the appliance, including:

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

11. 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.

12. 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.

Table of Contents

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

6.2.1 Minimum Required OpenSSL CSR

6.2.2 Recommended OpenSSL CSR

6.2.3 OpenSSL CSR for multiple DNS names and IPs

6.2.4 Validate the CSR using OpenSSL

6.2.5 Validate the issued certificate using OpenSSL

6.2.6 Key Encipherment compatibility option

7. Preparing the issued certificate

7.1 Preparation using a PKCS#12 fiile

7.1.1 Extract an unencrypted private key from a PKCS#12 file

7.1.2 Extract the server certificate

7.1.3 Extract the CA chain

7.2 Preparation using a base64-encoded key file

7.3 Create the server certificate bundle

8. Validate the files

8.1 Review the certificate

8.2 Validate the private key

8.3 Confirm that the certificate and key match

9. Use a self-signed certificate

9.1 Automatically generating a self-signed certificate

9.2 Using OpenSSL to generate a self-signed certificate

9.3 Self-signed SAN certificate for multiple appliances

10. Upload the certificate to XONA

11. 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

12. Security recommendations