Questo contenuto non è disponibile nella lingua selezionata.
Chapter 3. Supported standards and protocols
Red Hat Certificate System is based on many public and standard protocols and RFCs, to ensure the best possible performance and interoperability. The major standards and protocols used or supported by Certificate System {VER} are outlined in this chapter, to help administrators plan their client services effectively.
3.1. TLS, ECC, and RSA Copia collegamentoCollegamento copiato negli appunti!
The Transport Layer Security (TLS) protocol is an universally accepted standard for authenticated and encrypted communication between clients and servers. Both client and server authentication occur over TLS.
TLS uses a combination of public-key and symmetric-key encryption. Symmetric-key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An TLS session always begins with an exchange of messages called handshake, initial communication between the server and client. The handshake allows the server to authenticate itself to the client using public-key techniques, optionally allows the client to authenticate to the server, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and integrity verification during the session that follows.
TLS supports a variety of different cryptographic algorithms, or ciphers, for operations such as authenticating the server and client, transmitting certificates, and establishing session keys. Clients and servers may support different cipher suites, or sets of ciphers. Among other functions, the handshake determines how the server and client negotiate which cipher suite is used to authenticate each other, to transmit certificates, and to establish session keys.
Key-exchange algorithms like RSA and Elliptic Curve Diffie-Hellman (ECDH) govern the way the server and client determine the symmetric keys to use during an TLS session. TLS supports ECC (Elliptic Curve Cryptography) cipher suites, as well as RSA. The Certificate System supports both RSA and ECC public-key cryptographic systems natively.
In more recent practise, key-exchange algorithms are being superseded by key-agreement protocols where each of the two or more parties can influence the outcome when establishing a common key for secure communication. Key agreement is preferrable to key exchange because it allows for Perfect Forward Secrecy (PFS) to be implemented. When PFS is used, random public keys (also called temporary cipher parameters or ephemeral keys) are generated for each session by a non-deterministic algorithm for the purposes of key agreement. As a result, there is no single secret value which could lead to the compromise of multiple messages, protecting past and future communication alike.
Longer RSA keys are required to provide security as computing capabilities increase. The recommended RSA key-length is 2048 bits. Though many servers continue to use 1024-bit keys, servers should migrate to at least 2048 bits. For 64-bit machines, consider using stronger keys. All CAs should use at least 2048-bit keys, and stronger keys (such as 3072 or 4096 bits) if possible.
3.1.1. Supported cipher suites Copia collegamentoCollegamento copiato negli appunti!
Cipher and hashing algorithms are in a constant flux with regard to various vulnerabilities and security strength. As a general rule, Red Hat Certificate System follows the NIST guideline and supports TLS 1.1 and TLS 1.2 cipher suites pertaining to the server keys.
3.1.2. Recommended TLS cipher suites Copia collegamentoCollegamento copiato negli appunti!
The Transport Layer Security (TLS) protocol is a universally accepted standard for authenticated and encrypted communication between clients and servers. Red Hat Certificate System supports TLS 1.1 and 1.2.
Red Hat Certificate System supports the following cipher suites when the server is acting either as a server or as a client:
- ECC* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- RSA* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
3.2. Allowed key algorithms and their sizes Copia collegamentoCollegamento copiato negli appunti!
Red Hat Certificate System supports the following key algorithms and sizes if they are provided by the underlying PKCS #11 module.
Allowed RSA key sizes:
- 2048 bits or greater
Allowed EC curves or equivalent as defined in the FIPS PUB 186-4 standard:
- nistp256
- nistp384
- nistp521
3.3. Allowed hash functions Copia collegamentoCollegamento copiato negli appunti!
The following keyed hash messages authentication (HMAC) are allowed:
- SHA-256
- SHA-384
- SHA-512
The following cryptographic hashing functions are allowed:
- SHA-256
- SHA-384
- SHA-512
3.4. IPv4 and IPv6 addresses Copia collegamentoCollegamento copiato negli appunti!
Certificate System supports both IPv4 addresses and IPv6 addresses. In a very wide variety of circumstances, Certificate System subsystems or operations reference a host name or IP address; supporting both IPv4- and IPv6-style addresses ensures forward compatibility with network protocols. The operations that support IPv6 connections include the following:
- Communications between subsystems, including between the TPS, TKS, and CA and for joining security domains
- Token operations between the TPS and the Enterprise Security Client
- Subsystem logging
- Access control instructions
-
Operations performed with Certificate System tools, including the
pki
utility, the Subject Alt Name Extension tool, HttpClient, and the Bulk Issuance Tool -
Client communications, including both the
pkiconsole
utility and IPv6-enabled browsers for web services - Certificate request names and certificate subject names, including user, server, and router certificates
- Publishing
- Connecting to LDAP databases for internal databases and authentication directories
Any time a host name or URL is referenced, an IP address can be used:
-
An IPv4 address must be in the format
n.n.n.n
orn.n.n.n,m.m.m.m
. For example,128.21.39.40
or128.21.39.40,255.255.255.00
. - An IPv6 address uses a 128-bit namespace, with the IPv6 address separated by colons and the netmask separated by periods. For example, 0:0:0:0:0:0:13.1.68.3, FF01::43, or 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0.
If DNS is properly configured, then an IPv4 or IPv6 address can be used to connect to the web services pages and to the subsystem Java consoles. The most common method is to use fully-qualified domain names:
https://ipv6host.example.com:8443/ca/services pkiconsole https://ipv6host.example.com:8443/ca
https://ipv6host.example.com:8443/ca/services
pkiconsole https://ipv6host.example.com:8443/ca
To use IPv6 numeric addresses, replace the fully-qualified domain name in the URL with the IPv6 address, enclosed in brackets: [<IPv6_address>]
. For example:
https://[00:00:00:00:123:456:789:00:]:8443/ca/services pkiconsole https://[00:00:00:00:123:456:789:00:]:8443/ca
https://[00:00:00:00:123:456:789:00:]:8443/ca/services
pkiconsole https://[00:00:00:00:123:456:789:00:]:8443/ca
3.5. Supported PKIX formats and protocols Copia collegamentoCollegamento copiato negli appunti!
The Certificate System supports many of the protocols and formats defined in Public-Key Infrastructure (X.509) by the IETF. In addition to the PKIX standards listed here, other PKIX-listed standards are available at the IETF Datatracker website.
Format or Protocol | RFC or Draft | Description |
---|---|---|
X.509 version 1 and version 3 | Digital certificate formats recommended by the International Telecommunications Union (ITU). | |
Certificate Request Message Format (CRMF) | RFC 4211 | A message format to send a certificate request to a CA. |
Certificate Management Message Formats (CMMF) | Message formats to send certificate requests and revocation requests from end entities to a CA and to return information to end entities. CMMF has been subsumed by another standard, CMC. | |
Certificate Management Messages over CS (CMC) | RFC 5274 | A general interface to public-key certification products based on CS and PKCS #10, including a certificate enrollment protocol for RSA-signed certificates with Diffie-Hellman public-keys. CMC incorporates CRMF and CMMF. |
Cryptographic Message Syntax (CMS) | RFC 2630 | A superset of PKCS #7 syntax used for digital signatures and encryption. |
PKIX Certificate and CRL Profile | RFC 5280 | A standard developed by the IETF for a public-key infrastructure for the Internet. It specifies profiles for certificates and CRLs. |
Online Certificate Status Protocol (OCSP) | RFC 6960 | A protocol useful in determining the current status of a digital certificate without requiring CRLs. |
Automated Certificate Management Environment (ACME) | RFC 8555 | A protocol for automated identifier validation and certificate issuance. |
Enrollment over Secure Transport (EST) | RFC 7030 | A cryptographic protocol designed to provide secure certificate enrollment for devices. |