You are viewing the documentation for an outdated or unreleased 9.5 version.
This page is also available in versions: 7.7, 7.8, 8.0, 8.1, 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.7 (current), devel
This page is also available in versions: 7.7, 7.8, 8.0, 8.1, 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.7 (current), devel
Differences
This shows you the differences between two versions of the page.
| — |
9.5:documentation:modules_ca [2018/03/27 07:48] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | <- .:modules_crt | ^ .:start | Documentation ^ .:modules_sms -> | ||
| + | ====== Modules - Certificate authority [ca] ====== | ||
| + | |||
| + | <note warning>Deprecated module - use [[.:modules_crt|]]</note> | ||
| + | |||
| + | CA module consists of two main parts | ||
| + | * **CAW** - our CA implementation | ||
| + | * **cert management** (GUI, logic, API) | ||
| + | |||
| + | CA module was designed to handle various certificate authority implementations via specific "drivers". | ||
| + | Currently, there is one driver implemented - the CAW driver that handles the communication with CAW certificate authority (bundled in [ca]) | ||
| + | |||
| + | Conceptually every certificate authority architecture consists of three parts, all of them are implemented in our [ca] module: | ||
| + | * **Registration Authority (RA)** - handles identity validation, processes for certificate issuance, GUI (in CzechIdM part) | ||
| + | * **Certificate Authority (CA)** - issues certificates and CRLs (in CAW part) | ||
| + | * **Validation Authority (VA)** - handles validation requests, in our solution implemented together with CA by means of Certificate Revocation Lists (in CAW part) | ||
| + | |||
| + | ===== [ca] architecture ===== | ||
| + | |||
| + | [ca] module consists of those basic parts: | ||
| + | * **GUI** - Users can manage their certificates or request a new one via standard CzechIdM web GUI | ||
| + | * **Registration authority** - When user requests for a certificate, the request is processed by appropriate driver. | ||
| + | * **Certificate store** - users' certificates are stored in CzechIdM for future download or e.g. provisioning (send to other managed system) | ||
| + | * **Drivers** - Driver implements mainly the communication mechanism between CzechIdM and CA (e.g. CAW or Microsoft CA). Currently CzechIdM provides the driver for CAW, others can be implemented on demand. If the request from registration authority does not contain CSR, driver creates it. | ||
| + | * **CAW** - Our CA implementation based on openssl. | ||
| + | * **RESTful API** - Standard communication API. Use it e.g. when users request for a new certificate via some external registration authority software. | ||
| + | |||
| + | {{ :devel:documentation:ca_new_without_ad.png | CA module architecture}} | ||
| + | |||
| + | |||
| + | ===== [ca] main features ===== | ||
| + | |||
| + | * Certificate authority GUI is built atop the CzechIdM web interface. | ||
| + | * User can request a certificate for himself only if he has a role which allows it. A role can be granted to users automatically or the users can request it through standard functionality of the identity manager. | ||
| + | * Certificate authority can work with supplied CSRs and it can also generate private key and certificate for ordinary users. When generating the certificate, a user must supply a passphrase. User's private key is encrypted with this passphrase when stored in the certificate authority - nobody, even admin, can access it without the passphrase. | ||
| + | * **User** | ||
| + | * fill out a **request** form (with request reason) when requesting a certificate. User's request for a certificate can be approved first (i.e. by his manager). Configurable. | ||
| + | * can **download** his certificate as many times as he wishes. If he chooses to download certificate bundled with private key, he must supply the same passphrase as he did when he was generating the key. User can download a certificate in PKCS#12 format, with or without bundled certificate chain. | ||
| + | * can **prolong** his certificate. This functionality can be disabled. Expired and revoked certificates cannot be prolonged. | ||
| + | * can **revoke** his certificate. | ||
| + | * can **validate** the certificate. | ||
| + | * **Administrator** | ||
| + | * can **request** a certificate in the name of an user. | ||
| + | * can **revoke, download** any certificate. | ||
| + | * User's certificates are automatically revoked upon user's Contract termination. | ||
| + | * CA module **notifies user/administrator/both** if the certificate is about to **expire**, was **revoked** a new certificate **was issued**. | ||
| + | * CA module automatically handles **issuing CRLs**. | ||
| + | * CA module issues certificates **signed by its private key**. | ||
| + | * CA module has a **RESTful API**. | ||
| + | * Validation authority enables everybody to check if a certificate is valid. It is realized by **CRL** which is downloadable on a web URL. | ||
| + | * Third-party applications using CRLs has to refresh their CRL copy on a regular basis. (OCSP support is not supported yet) | ||
| + | |||
| + | ===== Admin guide ===== | ||
| + | * [[.modules_crt:adm:caw_driver]] | ||
| + | |||
| + | ===== Devel guide ===== | ||
| + | * [[.modules_ca:dev:certification_authority|Building and installing CA]] | ||