it keeps the information updated, and prevents it starts to talk to an non untrustful CA.

   Store and check the CA Certificate Chain to ensure we are talking to the same CA. Save the CA Cert. Chain for future usage.

  and implement other things nicer.

  SLAPOS_TEST_IPVx isnt available for erp5 tests, and discover based on zserver address
  is a common way of doing it.

   This allows the administrator set caucase url and invoke bootstrap to set the credentials (user/key to CAU api)

  Ensure it has a new between the 2

   While generate the first certificate include more typical information for the CSR, like city, company, email, state, country.

   Reuse the values from User Certificate to generate the next CSR, in case this API is called by the Certificate Login. This is consistent with the previous legacy API (portal_certificate_authority) that will rely on openssl.cnf defined versions.

   The connector is mostly tests via Person/Certificate Login tests, this tests aims to cover the extra portion.

  Use specific reference reduces the confusion on what default means, since we
  can have multiple connectors for multiple purposes one day.

   Change the property used to clearly identify if this document used caucase or some previous legacy implementation not supported anymore.

   In such case, invalidate the Certificate Login is enough to prevent access.

  This TestCase allows to start a Caucase Server to be
  used on tests. The code is inspired on Kedifa tests.

This is simpler to manage and include extra methods

  This tool will be replaced by caucase implementation and drop
  related code that is not needed anymore

  Rather them use filesystem openssl CA, contact Caucase Service for sign certificates.

Prevent potential errors to be returned with 201 status

Follow nexedi/erp5@a659b01c

Same behaviour than File/Image

It is needed if a module contains multiple object's portal types.