The Access tab and subtabs offer the following access configuration options.
Server TLS Certificates
Server side TLS certificates are used to authenticate the Hardware Appliance to the outside world. The information in the certificate must match the information the client is using to connect and the client must trust the issuer of the certificate.
The following values are normally set in an TLS certificate (assuming that the host is hostname.example.com and the IP is always 10.10.10.10):
Setting the hostname to an IP address will also work.
The initial certificates issued for the network interfaces are self-signed. During the installation they are replaced with certificates issued by the initial Management CA.
If you already have an existing TLS CA that is trusted by browsers in your organization, you can replace the certificates in this view.
- Click Generate a new key pair.
- Create a Certificate Signing Request (CSR).
- Send the CSR to your CA together with the information you would like to have in the certificate. Note that some implementations (e.g. Java) require a matching IP address or DNS entry in the certificate.
- Upload the issued certificate in PEM format with full certificate chain.
Note that the information in the CSR isn't set to anything useful. This is the normal EJBCA way of doing things, where the information inside the CSR is not trusted and overridden by whatever values the RA officer finds acceptable.
Client TLS Trust Anchors
Client side TLS certificates are used to authenticate users or external systems to the Hardware Appliance. For a client certificate to even be considered by the Hardware Appliance for authentication it must be issued by a CA that is trusted by the Hardware Appliance. If the client certificate is trusted, the Hardware Appliance or application firmware will try to match the information in the certificate to a list of rules (accounts).
Note that no revocation checking has been implemented yet.
Trusted CAs for client authentication
You can configure different trusted certificates (trust anchors) for each network interface. If you want to use client TLS certificates from an external CA, you need to replace the trusted certificate. To avoid locking yourself out of the Hardware Appliance, first add the appropriate matching rules in the subtab Access > Appliance accounts, so that you can reconnect and continue to administer the Hardware Appliance after the trusted certificate is replaced.
To configure a new trusted certificate, simply upload the CA certificate (in PEM format) and confirm the change. After a short delay, you will be able to reconnect using the client TLS certificate issued by this trusted CA.
Client TLS OCSP
Use this tab to configure whether and how the Hardware Appliance performs OCSP verifications on TLS client certificates of incoming connections. Currently, the options are available for the Application interface only. The configuration for the Management interface is currently disabled. This is to avoid the danger of locking yourself out.
You have the following options:
The front proxy will not do any OCSP checking on the TLS client side certificates.
The front proxy will reach out the OCSP Responder specified in the client certificate (AIA). If that is not specified, it will fallback to the internal EJBCA Management CA.
The front proxy will reach out the OCSP Responder specified in the client certificate (AIA). If that is not specified, it will fallback to the specified URI.
These are valid characters for the URI:
- Special characters _ . - + / @ : .
Save / Revert:
Click Save to confirm your changes, Revert to undo them.
Changing the configuration results in a restart of the front end proxy. WebConf will then be unavailable for a few seconds.
If the automatic reload ends up in a browser error, just reload the page.
Hardware Appliance management accounts are matching rules that will be processed when a user tries to log in.
You have the following options:
Select the desired rule. These options are supported:
clientcert: Client TLS certificates authentication
sharedsecret: Shared secret (password) authentication
The required MatchValue depends on the selected MatchType:
MatchValue for clientcert: The match value is the entire subject distinguisher name of the certificate., as for example "CN=SuperAdmin,O=PrimeKey Labs C,C=DE".
MatchValue for sharedsecret: The match value is the shared secret.
We strongly recommend to use the clientcert option. Authentication via sharedsecret might disappear in future releases of the Hardware Appliance.
Click this button to add the rule with the specified MatchType and MatchValue.
Click this button to remove the rule in that line.