One Identity Safeguard for Privileged Sessions (SPS) can check the validity of certificates using the certificates and certificate revocation lists of the certificate authorities (CA) that issued the certificates. This can be used to verify the certificates of the servers in TLS connections.
Trust stores serve as local certificate storages where you can store the certificate chains of trusted CAs. Create and configure custom trust stores to verify the certificates in TLS connections. Note that you cannot modify the built-in trust store, which contains common CA certificates that the operational system of SPS uses.
You can use custom trust stores in the following locations:
Basic Settings > Management > Syslog — Check server certificate. For more information, see Configuring system logging.
Basic Settings > Management > Universal SIEM forwarder — TLS with certificate validation. For more information, see Using the universal SIEM forwarder.
Users & Access Control > Settings > Authentication settings — Configuring X.509 authentication. For more information, see Authenticating users with X.509 certificates.
Users & Access Control > Settings > Authentication settings — Configuring LDAP, TLS and STARTLS encryption method. For more information, see Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database
Policies > LDAP Servers — Configuring encryption. For more information, see Authenticating users to an LDAP server.
To specify cipher settings and version requirements that SPS uses for establishing TLS connections in the Cryptography Settings section, navigate to Basic Settings > Trust Stores.
Figure 188: Basic Settings > Trust Stores — Cryptography settings
Cipher strength specifies the cipher string OpenSSL will use. The following settings options are possible:
Recommended: this setting only uses ciphers with adequate security level.
Custom: this setting allows you to specify the list of ciphers you want to permit SPS to use in the connection. This setting is only recommended to ensure compatibility with older systems. For more details on customizing this list, check the 'openssl-ciphers' manual page on your SPS appliance.
For example: ALL:!aNULL:@STRENGTH
Minimum TLS version specifies the minimal TLS version SPS will offer during negotiation. The following settings options are possible:
TLS 1.2: this setting will only offer TLS version 1.2 during negotiation. This is the recommended setting.
TLS 1.1: this setting will offer TLS version 1.1 and later versions during negotiation.
TLS 1.0: this setting will offer TLS version 1.0 and later versions during negotiation.
Maximum TLS version specifies the maximal TLS version SPS will offer during negotiation. The following settings options are possible:
TLS 1.2: this setting will only offer TLS version 1.2 during negotiation. This is the recommended setting.
TLS 1.1: this setting will offer TLS version 1.1 and later versions during negotiation.
TLS 1.0: this setting will offer TLS version 1.0 and later versions during negotiation.
Latest: this setting will offer the latest TLS version during negotiation.
NOTE: Note that SPS only permits TLS-encrypted connections. SSLv3 is not supported.
NOTE: TLS 1.1 and 1.2 support for Windows 7 Service Pack 1 (SP1) and for Windows Server 2008 R2 Service Pack 2 (SP2) is not available by default. For more information about the requirements and process of enabling this feature, click here or contact our Support Team.
To create a custom trust store or edit an existing custom trust store
Navigate to Basic Settings > Trust Stores.
Figure 189: Basic Settings > Trust Stores
In the Custom trust stores section, click Add new Trust Store. To change the settings of an existing trust store, click Edit.
The Add new trust store or Edit trust store window opens.
Figure 190: Basic Settings > Trust Stores — Add new trust store
In the Trust Store Name field, enter a name for the trust store. For example ts1.
To add the certificate of the CA to the trust store that will be used to validate the certificates, click Add certificate. The Add certificate window opens.
Paste or drag the PEM certificate file to the Key content field. You can also click Browse to navigate to the PEM certificate file on your computer.
Figure 191: Basic Settings > Trust Stores — Add certificate
You will have to upload all the CA certificates from the users' certificate chains (including the root CA). Therefore, these CA certificates must be available on your computer in PEM format.
The certificates of the users must contain the user name used to authenticate on SPS. You must know which certificate field will contain the user names (for example, CN or UID).
The certificates must be imported into the browsers of the users. SPS offers the possibility to authenticate with a certificate only if a personal certificate is available in the browser.
NOTE:
You can only upload a single PEM certificate.
You cannot upload multiple PEM certificates in a single file.
To upload more PEM certificates, add them as single entities one by one.
Click Add.
Set the revocation check type for the trust store.
None: Do not check certificate revocation status.
Leaf: Check the revocation status of the peer's certificate, but do not check the revocation status of the CA certificates in the chain.
Full: Check the revocation status of the peer's certificate and all CA certificates in the chain.
If you set the revocation check type to Leaf or Full, click Add new CRL URL to specify the CRL distribution point(s) of the CA that issued the peers' certificates.
Enter the URL of the Certificate Revocation List (CRL) of the CA into the CRL URL field. Certificates appearing on the CRL list will be automatically rejected.
Click Remove to remove a CRL distribution point from the trust store.
Click Save and close the window.
Click .
At a number of places, One Identity Safeguard for Privileged Sessions (SPS) can generate the server certificates on the fly. This technique is used for example in SSL-encrypted RDP sessions, RDP sessions that use Network Level Authentication (CredSSP), or SSH connections that use X.509-based authentication.
NOTE: Note the following points about using signing CAs:
Signing CAs require a CA certificate permitted to sign certificates, and also the corresponding private key.
These CAs cannot be used to sign audit trails. For details on how to configure the certificates used to sign audit trails, see Digitally signing audit trails.
The version of the generated certificates will be the same as the version of the signing CA.
SPS ignores the CRL (from the crlDistributionPoints extension) of the signing CA when generating certificates. If you want to include a CRL in the generated certificates, you must set it manually. See the following steps for details.
To create a signing CA using the built-in signing CA solution
Navigate to Policies > Signing CAs and click .
Select Local.
Enter a name for the CA into the topmost field.
Figure 192: Policies > Signing CAs — Creating Signing CAs - Local
To upload a CA certificate and its private key, complete the following steps. Skip this step if you want to generate a CA on SPS.
Click Edit in the CA X.509 certificate field and upload the certificate of the certificate authority. Alternatively, you can upload a certificate chain, where one member of the chain is the CA that will sign the certificates.
Click Edit in the CA private key field and upload the private key of the certificate authority that will sign the certificates.
(Optional) Enter the URL of the Certificate Revocation List (CRL) that you generated using your Certificate Authority in your Public Key Infrastructure (PKI) solution. The URL pointing to this CRL will be included in the certificate. This is the CRL information that will be shown to clients connecting to SPS.
Note that the CRL list is not generated by the internal CA of SPS. The list must come from your own PKI solution.
Click .
To generate a CA certificate on SPS, complete the following steps:
Enter the Common Name for the CA certificate into the Common Name field. This name will be visible in the Issued By field of the certificates signed by this CA.
Fill the other fields as required, then click Generate private key and certificate.
Click .
To create a signing CA using an external signing CA plugin
Navigate to Policies > Signing CAs and click .
Select External Plugin.
Enter a name for the CA into the topmost field.
Figure 193: Policies > Signing CAs — Creating Signing CAs - External Plugin
From the Plugin field, select an uploaded external plugin using the drop-down menu.
To be able to select from the drop-down menu, you must have an external plugin uploaded in Basic Settings > Plugins.
For more information about how to create an external Signing CA plugin, see Creating an external Signing CA.
Optionally, fill the Configuration field as required by the uploaded plugin.
The input you enter in the Configuration field is passed down to the plugin.
The External Signing CA plugin's purpose is to generate certificate and private key pairs signed by a Certificate Authority. By using this type of plugin the certificate signing can be tailored to fit any custom requirement.
The plugin is a .zip file containing a MANIFEST and a main.py file.
The MANIFEST file is a YAML file, and should conform to version 1.2 of the YAML specification. It should contain the following information about the plugin:
api: 1.0 type: signingca name: MySigningCaPlugin version: 1.0 description: My custom Signing CA
The type of the plugin must be signingca.
A Plugin class containing the following methods must be defined in the main.py file:
generate_for_addresses: generates a key/certificate pair for the given addresses (IP/DNS)
generate_for_username: generates a key/certificate pair for the given username
generate_for_subject: generates a key/certificate pair for the given subject values
Each method must take the following arguments:
generate_for_addresses:
addresses: {list of str} - contains either IP or DNS addresses for which the certificate shall be issued
keytype: {str} - contains a fixed value of 'RSA' or 'DSS' indicating the requested key type for the certificate
generate_for_username:
username {str} - contains the username for which the certificate shall be issued
keytype: {str} - contains a fixed value of 'RSA' or 'DSS' indicating the requested key type for the certificate
generate_for_subject:
subject {list of (str, str)} - contains the certificate subject as type-value pairs (tuples). Valid types are the following:
'C' country name
'ST' state or province name
'L' locality name
'O' orangization name
'OU' organizational unit
'CN' common name
'emailAddress' email address
keytype: {str} - contains a fixed value of 'RSA' or 'DSS' indicating the requested key type for the certificate
Each method returns a {dict} that must have the following keys:
key: {str} the generated key
chain: {list of str} a PEM encoded certificate chain containing the generated certificate as the first element
The code below demonstrates a simple plugin that can sign certificates with a built in CA. By default it uses a pre-generated CA certificate and key to complete signing requests. To use a custom certificate, provide a certificate and a key in a python dict format in the configuration field.
NOTE: If you wish to try this sample code, you will need to provide a MANIFEST file (see below) and the following package dependencies in the .zip file alongside the plugin:
asn1crypto
certbuilder
oscrypto
main.py:
#!/usr/bin/env pluginwrapper3 # # Copyright (c) One Identity # All Rights Reserved. # from ast import literal_eval from certbuilder import CertificateBuilder, pem_armor_certificate from ipaddress import ip_address from oscrypto import asymmetric class Plugin(object): plugin_root_ca = """-----BEGIN CERTIFICATE----- MIIDhjCCAm6gAwIBAgIIW+mOlk1Cu4swDQYJKoZIhvcNAQELBQAwYTELMAkGA1UE BhMCSFUxETAPBgNVBAgMCEJ1ZGFwZXN0MREwDwYDVQQHDAhCdWRhcGVzdDEQMA4G A1UECgwHQmFsYWJpdDEaMBgGA1UEAwwRQmFsYWJpdCBQbHVnaW4gQ0EwHhcNMTgx MTEyMTQzMDQ2WhcNMTkxMTEyMTQzMDQ2WjBhMQswCQYDVQQGEwJIVTERMA8GA1UE CAwIQnVkYXBlc3QxETAPBgNVBAcMCEJ1ZGFwZXN0MRAwDgYDVQQKDAdCYWxhYml0 MRowGAYDVQQDDBFCYWxhYml0IFBsdWdpbiBDQTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAO73W0ONVwIaBJas+qUe0VBZ4rtk6PtzRNenZcBkTCkITuuF DAQ3T1qLUsCyQ4uHMo+yKZUqR3HxbWGxS2l4IaHP6Hbna2kNEyYEsg16mGVUz6tc D6bxFu3EpB7eU/OXh8RS8URIfZbLNrql1sKe7k1hpXUDS74Ra/avUIYKIpZ5sCjs F6MBZWz5u3tNUa53xVmqgpnQ6pozN+OQ6k74DjK4xqWqJgTWcN6rxZ9k2voQYE3s H66jl53q+Zl0D4w/AEW5W3OYNHJtx3tsc36sD2i0doqBCAAvflcSDEs7TXhfXSkC qCBKyx8ics5EL9h49MDPGwDTehzwvXusz8LlxeMCAwEAAaNCMEAwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUyFWUMJli0q5CtJOp25IqK2M70oAwDgYDVR0PAQH/ BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IBAQCWoQCJPqfM4Sjg0R2O42yrE2GtQsXf Qb3Dur+CefWLcvjI28t1xuj31khDgpNTwk4IVYrvarNX33C3tjYKgcimwWRMijbA p8kZzFajOZSWC32CQtkWL79LLkJCTJB7b/4E41oNQPHtOoNCqFY+uQogP90qZ1w1 xlFX8ie/W3cuqhfzW6+/M3iCIwdjhBquvOo6mE3t2/lUcGXE20GayFsKnEmgpDJa nxoG1+m+s5zCwDuukX8Lr1O7maTMwNVhm5P5QWeEPbGRN7yw+CfzcvPIbFYwnZ5x XeC9Vtoj2Jbom8RV9uus8R5LfYBJ+HZh74wbGhIC2Kf9LrJTK7r92uVA -----END CERTIFICATE-----""" plugin_root_ca_key = """-----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDu91tDjVcCGgSW rPqlHtFQWeK7ZOj7c0TXp2XAZEwpCE7rhQwEN09ai1LAskOLhzKPsimVKkdx8W1h sUtpeCGhz+h252tpDRMmBLINephlVM+rXA+m8RbtxKQe3lPzl4fEUvFESH2Wyza6 pdbCnu5NYaV1A0u+EWv2r1CGCiKWebAo7BejAWVs+bt7TVGud8VZqoKZ0OqaMzfj kOpO+A4yuMalqiYE1nDeq8WfZNr6EGBN7B+uo5ed6vmZdA+MPwBFuVtzmDRybcd7 bHN+rA9otHaKgQgAL35XEgxLO014X10pAqggSssfInLORC/YePTAzxsA03oc8L17 rM/C5cXjAgMBAAECggEBAIucxpw76naW3tFtNG7eB2pLaZUUSq4F1VWtPlxd/MUI Tpt5OuEHs3vx5CIixCWzkk2zyGmWrvEaHU6zN5ziC7wu7ODzKaTRd7uBiMkpM/oX x9CU06w0NLIrbbt/J0ss36xKzRyYwY8lIM+Bbmx8UDuzbehkSY89PHd+S6xUJYsF YmOVM00wx1N6yZGKHUV9GLRnysHb+DBbjGIcjDqmlsdyuAzlB7/DAeToLFNkZvzx Qzza6whMILXS9Qp39dzn7nJuJywfoOAX2q5LgOrPise2QY1FuAy0GTfqvBDR1eGd NwFW5YtH89l347AIDPgklKvKaii2iIw1ZEMf1AlX7mECgYEA+0JM9sToMgLhHJDj cUsznVn3xzjDT/4O95LdAq1fVrn10wh/SwGCBBPMHQkV1nS70d//1aGctZLWk5+F K3aPGV9Eas70mOGNcXdU1ITpFNuVfbKK8uH5NF/oEuoD4zRabunrj/zEk0Qu/D9v pN4qEwJoV1SD/9HpfpaUG/xuBLECgYEA83mtE34zYTY2TLBr4HvoiWrFYoEpPldN 64oD+w1/D0Wd9hxCyzO3y2SmrBmmbzoawTckxD/VKndeRdV5dLlEnAV4F35bPsQl dRJJEAAQPqqc1z4x6c2my27WPSbm4mIcvfTc65UFu4ovm/koywc96fwvpTX6JIN1 X8zHZ/tQaNMCgYEAl3yk3I9hk22K/ecZSiBWEUPCETpW/66kpX3FhKy085wQ61iP LtDM69pn0QW+RduBtgsAu3PCAPN0LfManlbP9jMrE96NOHOdDNEusycjRHET04JH JiM6VeqRCH5RM7ZH4+FjJh/3APc2AN3aWSOdaHKmKCkLoLyVs73jtG/ggTECgYBp reCf22E1yrAa7WCFmYK/UqbGMMXUF1Ts7YT4zUzfNhpwHqgnRxV5pQBrJt8E3DWM tACzZfmCazlyGkyTi27qQb10hRXZ0o1nmT45Qa3LZYaaLpa/otHI7xzyghYpIOjU 0pmpb4+DbWFo0+cO6N/I1ftgPGOMwbqKkHnk+kJWnQKBgQDQwITXna8OVjn86AQP m36JHXi0RNVO/x4+b8T7nurU6XCPIzE0PxfVVSXXsbKTWlq48GIw9ZNpPKPSTCQy fnYC+Pcu+4A+bfUwFk21khnN/fP5vyFlFhTrGneZeKWhUxv5iOqASEaizfOePmtj et/4B9LUf9KQFstlhuIR4AP2OA== -----END PRIVATE KEY-----""" def __init__(self, configuration=""): self.cert_x509name = { 'country_name': 'HU', 'state_or_province_name': 'Budapest', 'locality_name': 'Budapest', 'organization_name': 'One Identity', 'common_name': '', } self.cert_alt_domains = [] self.cert_alt_ips = [] if configuration is not "": try: configdict = literal_eval(configuration) self.plugin_root_ca = configdict['ca'] self.plugin_root_ca_key = configdict['key'] except Exception: pass self.root_ca_certificate = asymmetric.load_certificate(bytes(self.plugin_root_ca, 'utf-8')) self.root_ca_key = asymmetric.load_private_key(bytes(self.plugin_root_ca_key, 'utf-8')) def _sign_certificate(self): end_entity_public_key, end_entity_private_key = asymmetric.generate_pair(self.cert_keytype, bit_size=2048) end_entity_private_key = asymmetric.dump_private_key(end_entity_private_key, None) end_entity_subject = self.cert_x509name builder = CertificateBuilder( end_entity_subject, end_entity_public_key ) builder.subject_alt_domains = self.cert_alt_domains builder.subject_alt_ips = self.cert_alt_ips builder.issuer = self.root_ca_certificate end_entity_certificate = builder.build(self.root_ca_key) end_entity_certificate = pem_armor_certificate(end_entity_certificate) return end_entity_certificate, end_entity_private_key _subject_type_mapping = { 'C': 'country_name', 'ST': 'state_or_province_name', 'L': 'locality_name', 'O': 'organization_name', 'OU': 'organizational_unit_name', 'CN': 'common_name', 'emailAddress': 'email_address', } def _set_certificate_x509_name(self, x509name): for (t, v) in x509name: self.cert_x509name[self._subject_type_mapping[t]] = v def _set_certificate_keytype(self, keytype): # Certbuilder lists DSS key as DSA so we have to translate the string here if keytype == "dss": keytype = "dsa" if keytype not in ['dsa', 'rsa']: raise ValueError('Certificate type should be either \'rsa\' or \'dss\'') else: self.cert_keytype = keytype def _set_certificate_cn(self, cn): self.cert_x509name['common_name'] = cn def _set_certificate_addresses(self, addresses): for address in addresses: try: ip_address(address) self.cert_alt_ips.append(address) except ValueError: self.cert_alt_domains.append(address) def _build_response(self, cert, key): return {'key': key.decode('ascii'), 'chain': [cert.decode('ascii'), self.plugin_root_ca]} def generate_for_addresses(self, addresses: list, keytype: str): self._set_certificate_keytype(keytype) self._set_certificate_addresses(addresses) self._set_certificate_cn(addresses[0]) return self._build_response( *self._sign_certificate() ) def generate_for_username(self, username: str, keytype: str): self._set_certificate_keytype(keytype) self._set_certificate_cn(username) return self._build_response( *self._sign_certificate() ) def generate_for_subject(self, x509name: list, keytype: str): self._set_certificate_keytype(keytype) self._set_certificate_x509_name(x509name) return self._build_response( *self._sign_certificate() )
Use the following snippet as the MANIFEST file:
# Name of the plugin, may contain [a-zA-Z0-9] name: HelloSigningCaPlugin # Version of the plugin, only for display purposes version: 0.1 # Type of the plugin - this is a signingca plugin type: signingca # API version of the SCB the plugin was written for, in major.minor format api: 1.0 # Free form description. description: This is an example plugin used for testing. # Entry point for the plugin (also for running with python3) entry_point: main.py
Local User Databases are available for HTTP, RDP, SSH and Telnet protocols, and can be used to authenticate the clients to credentials that are locally available on One Identity Safeguard for Privileged Sessions (SPS). Such credentials include passwords and public keys. Local User Databases are most commonly used in inband gateway authentication scenarios.
NOTE: To store credentials on SPS and use them to authenticate on the server, use a local Credential Store. For details, see Using credential stores for server-side authentication.
To create a Local User Database
Navigate to Policies > Local User Databases and click .
Enter the name of the Local User Database.
Click to add entries.
Figure 194: Policies > Local User Databases — Mapping keys
Enter the name of the user into the Username field.
NOTE: If you also use Usermapping policies, enter the username that the client will use on the server side. If you also use gateway authentication, the gateway username can be used as well.
If you use public-key based authentication on the client side, click the icon in the Public Keys field, and upload the public key of the client.
SPS will verify that a client trying to use the username set in Step 3 is authenticating itself with the private key that corresponds to the uploaded public key or certificate.
One Identity recommends using 2048-bit RSA keys (or stronger).
Repeat the above steps to add other users as required.
Click .
Navigate to the Authentication Policies tab of the respective protocol and select the Local User Database there.
© 2023 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy