 |
Xentara v2.0.3
User Manual
|
|
Xentara v2.0.3
User Manual
|
Xentara supports authentication of remote clients using certificates. This form of authentication can be used, for example, for mutually authenticated TLS (mTLS) connections, or for authentication of OPC UA clients.
When using certificate-based authentication, a client must identify itself using a certificate. The certificate is then examined by Xentara, and checked against a set of rules, to determine whether the certificate is accepted, and what roles should be assigned to the client. The certificate matching rules are configured in the Xentara client certificate configuration file.
Certificates are not secret, and therefore presenting a particular certificate is not proof that you are the legitimate owner of the certificate. An attacker can easily obtain a copy of any certificate and present it as their own. In order for a client to proove that it is the legitimate owner of the certificate, it must demonstrate that it posesses the private key belonging to the certificate. Since the private key is private, an attacker cannot easily obtain it, and cannot forge this proof of possession.
The proof of possession is performed by the protocol used to exchange the certificate. TLS and OPC UA, for example, perform a proof of possession when exchanging certificates. The proof of possession is performed automatically, and requires no special configuration or interaction.
When Xentara is presented with a client certificate for authentication, it first checks the certificate for general validity. Xentara performs the following validity checks before accepting any certificate:
If the certificate is not valid, it is rejected out of hand.
Once a certificate has passed the preliminary checks described above, it is matched against the certificate rules defined in the Xentara client certificate configuration file. The certificate rules determine whether the client that presented the certificate is granted access to Xentara, and what roles are assigned to it if so.
Certificate rules come in two flavours: explicit certificate rules, and trust-based certificate rules. Explicit rules are intended to be used for self-signed certificates, and trust-based rules are intended to be used for CA signed certificates. The two types of rules are explained in detail in the following chapters.
If a certificate matches at least one rule, then the client is granted access to Xentara. The client is automaticaly granted the built-in role “Everyone”, plus any additional roles specified in the rule. If a certificate matches more than one rule, then the client is assigned all of the roles specified in all of the rules it matched.
If the certificate matches no rules at all, then the remote client is denied access to Xentara completely.
In an explicit rule, the certificate is explicitly specified in the Xentara client certificate configuration file. The certificate can be specified in one of two ways: as a certificate path, or using the certificate’s fingerprint. An explicit certificate rule only ever matches a single certificate.
Explicit certificate rules can only be used for self-signed certificates. CA-signed certificates must be identified using trust-based rules.
In a certificate path rule, the certificate is copied as a PEM file to the computer running Xentara. The path to the certificate file is then specified in the configuration file. Xentara will load the certificate file, and compare the supplied certificate to the certificate from the file. If the two are the same, the supplied certificate matches the rule.
In a fingerprint rule, the fingerprint (aka thumbprint) of the certificate is specified in the configuration file. Xentara will calculate the fingerprint of the supplied certificate and compare it to the configured fingerprint. If the two are the same, the supplied certificate matches the rule.
You can use either the SHA-256 fingerprint or the SHA-1 fingerprint to identify the certificate. Note, however, that SHA-1 is considered insecure, and should be avoided. A skilled attacker may be able to generate a forged certificate that has the same SHA-1 fingerprint as a legitimate certificate, and thus gain unauthorized access to Xentara. SHA-256 fingerprints are considered secure, and are not vulnerable to this type of attack.
Trust-based certificate rules are generally used for certificates issued by a certificate authority (CA). Because the rules are trust-based, the root certificate of the certificate’s certificate chain must be trusted. Trust in the root CA can be established in two ways:
Once trust has been established, Xentara matches the certificate’s properties against a number of criteria. In order to match a rule, a certificate must match all the criteria in the rule. The following certificate properties can be checked by trust-based rules:
A trust-based rule must contain at least an issuer criterion, but may contain any number of additional criteria. Usually, however, a rule will either specify only the issuer, or contain at most one other criterion. An exception to this is the NTDS object SID criterion, which is used in combination with other criteria to guard against security vulnerabilities in Microsoft’s Active Directory Certificate Services.
Trust-based rules should not be used for self-signed certificates, as such certificates can generally not be trutsed. Use explicit certificate rules for self-signed certificates instead.
This criterion is mandatory. Each trust-based rule must contain an issuer criterion. An issuer criterion specifies the distinguished name of the issuer of the certificates. Only certificates with the given issuer name will match the rule.
This criterion specifies the serial number of the certificate. The serial numnber, together with the issuer, uniquely identifies a single certificate.
This criterion specifies the subject key identifier (SKI) that must be contained in the certificate’s subject key identifier extension.
The subject key identifier is generated by the issuer to identify certificates that contain a specific public key. The subject key identifier does not identify a specific certificate, but ensures that the certificate contains a specific public key. This means that the certificate can only be used by someone having access to the corresponding private key, which is generally only one person or entity. The rule will thus be valid for all future certificates issued to the holder of the same private key, irrespective of the certificate properties. This allows the certificate authority to re-issue a certificate with a different expiration date, or even a different subject name, without having to update this rule.
This criterion specifies the full distinguished name of the certificate’s subject, i.e. the person or entity the certificate was issued to. Using the subject name instead of the serial number to identify the certificate allows the certificate authority to re-issue a certificate with a different expiration date to the same recipient without having to update this rule.
This criterion specifies a partial distungished name, which must match the beginning of the certificate subject’s name. The subject name is considered to match if the leading, or most general RDNs (relative distinguished names) of the subject match the given prefix. The most general RDN is usually a country name (C) or a domain component (DC).
The prefix matches the
Consider, for example, tho following prefix:
This prefix will match, amongst others, the followong three names:
Only full RDNs are matched, and only in the given order. The following names are not matched:
Using the subject prefix allows you to match certificates issued to multiple subjects at once. The subject prefix can be used to match all subjects belonging to a specific organizational unit, for example.
This criterion specifies the hash of the public key contained in the certificate.
Matching the public key hash ensures that the certificate contains a specific public key. This means that the certificate can only be used by someone having access to the corresponding private key, which is generally only one person or entity. The rule will thus be valid for all future certificates issued to the holder of the same private key, irrespective of the certificate properties. This allows the certificate authority to re-issue a certificate with a different expiration date, or even a different subject name, without having to update this rule.
You can use either the SHA-256 hash or the SHA-1 hash of the public key. Note, however, that SHA-1 is considered insecure, and should be avoided. A skilled attacker may be able to generate a forged certificate that has the same SHA-1 public key hash as a legitimate certificate, and thus gain unauthorized access to Xentara. SHA-256 hashes are considered secure, and are not vulnerable to this type of attack.
This criterion specifies the NTDS object SID that must be contained in the certificate’s Microsoft specific ntdsCASecurityExt extension, described in 2.2.2.7.7.4 szOID_NTDS_CA_SECURITY_EXT in the Microsoft Open Specifications.
The NTDS object SID is used to mitigate a number of security vulnerabilities in Microsoft’s Active Directory Certificate Services (AD-CS) that may allow an attacker to create certificates with forged properties if certain types of certificate templates have been installed in the domain server.
This criterion should not be used on its own, but in combination with another criterion that is considered weak when mapping AD-CS certificates, as outlined in Microsoft Knowledge Base acticle KB5014754. Instead of using this criterion, it is strongly recommended to follow the guidelines outlined in KB5014754 and map AD-CS certificates using the certificate serial numbers, SKI, or public key hash.
When configuring certificate authentication using trust-based certificate rules, the certificate authority (CA) that issued the certificate must be trusted, so that Xentara can detect forgered certificates. If the root certificate of the issuer is altready a trusted root certificate, no further action is required.
Sometimes, however, it is desirable to accept certificates from a private enterprise CA that whose root certificate is not known or trusted. In this case, Xentara cannot verifiy that the certificate is not a forgery, because the root certificate cannot be checked for authenticity.
One solution to this problem is to install the enterprise CA’s root certificate as a trusted certificate within the operating system. Under Linux, this is usually done by copying the certificate to /usr/local/share/ca-certificates, and then running update-ca-certificates(8) as root. Under Windows, the Microsoft Certificate Manager Tool (certmgr.exe) can be used to manage trusted root certificates.
Installing the root certificate within the operating system requires absolute trust in the corresponding CA, however. Globally installed root certificates are trused system-wide, and the owner of the root certificate now has the power to issue certificates for any use and with any properties. These certificates will then be accepted not only by Xentara, but also by web browsers, SSH clients, OPC UA clients, and all other system components that use certificates to verify the identity of a communications partner. Even within Xentara, the owner of the certificate can now generate certificates that match any of the configured rules, even rules that were intended for other issuers. You should therefore only install the root certificates of your own enterprise CA in this manner, but never root certificates belonging to any third party.
A safer alternative to installing the root certificate using operating system tools, is to simply tell Xentara what the root certificate for specific issuer must look like. Xentara will then only allow that root certificate for certificates with that specific issuer, preventing the owner of the certificate from issuing certificates that match other rules that were intended for other issuers, and thus illegally gaining elevated privileges. It also prevents the owner of the certificate from forging certificates that will be accepted by other programs, like web browsers or SSH clients.
The root certificates for untrusted enterprise CAs are configured in the Xentara client certificate configuration file, next to the actual certificate rules.