Lines Matching +full:post +full:- +full:processing
26 - [Certificate Schema Definition](https://redfish.dmtf.org/schemas/v1/Certificate_v1.xml)
27 - [CertificateLocations Schema Definition](https://redfish.dmtf.org/schemas/v1/CertificateLocations…
28 - [CertificateService Schema Definition](https://redfish.dmtf.org/schemas/v1/CertificateService_v1.…
29 - [DSP-IS0008 DMTF's Redfish Certificate Management Document](https://www.dmtf.org/dsp/DSP-IS0008)
30 - [RFC 5246 - TLS 1.2 Specification](https://tools.ietf.org/html/rfc5246)
31 - [RFC 8446 - TLS 1.3 Specification](https://tools.ietf.org/html/rfc8446)
35 **Redfish API** - Redfish API as defined by DMTF **Redfish** - Redfish API
104 certificate stored there. New certificates can be uploaded by *POST*ing new
107 Example POST payload:
116 Should CA certificate get invalid (compromised, out-of-date, etc.) it is
119 unnecessarily for processing invalid certificates.
139 +-+
143 +------------+------------+
145 +---------+ Is certificate valid |
148 | +------------+------------+
152 | +-----------+-----------+
154 +----------+ Is URI whitelisted? |
156 | +-----------+-----------+
160 | +-----------+-----------+
162 +----------+ Is X-Token provided? |
164 | +-----------+-----------+
168 | +-----------+-----------+
170 +----------+ Is cookie provided? |
172 | +-----------+-----------+
176 | +-----------+-----------+
178 +----------+ Is Token provided? |
180 | +-----------+-----------+
184 | +---------------+--------------+
186 +------+ Is Basic auth data provided? +------+
188 | +------------------------------+ |
190 +-------------+--------------+ +-------------+--------------+
194 +-------------+--------------+ +-------------+--------------+
196 | +-+ |
197 +--------------------->*<--------------------+
198 +-+
203 done at the very beginning of HTTPS request processing. `OpenSSL` library is
208 - does KeyUsage contain required data ("digitalSignature" and "keyAgreement")
209 - does ExtendedKeyUsage contain required data (contains "clientAuth")
210 - public key meets minimal bit length requirement
211 - certificate has to be in it's validity period
212 - notBefore and notAfter fields have to contain valid time
213 - has to be properly signed by certificate authority
214 - certificate cannot be revoked
215 - certificate is well-formed according to X.509
216 - certificate cannot be self-signed
217 - issuer name has to match CA's subject name
219 After these checks a callback is invoked providing result of `user<->CA`
224 credentials according to processing sequence. It is recommended for user to use
231 configuration. Whitelist verification is always-on, because of Redfish
271 1. Flow described in [Process overview](#process-overview) should be tested, to
273 2. Validity period tests - to confirm that certificates that are not-yet-valid
274 and expired ones are not accepted, by both - changing validity periods in
278 4. Chain certificates verification - checking that chained certificates are
280 5. Negative tests for breaking user's certificate - invalid username, invalid