60 means no CA can validate the provided certificate.
The self-signed certificate we would generate would be no better.
60 means the frontend could serve some certificate, whatever its content,
which means the domain is minimally functional. So do not bother pushing
a self-signed certifiate, and do not signal a failure to the caller.

Also, make the output a bit nicer.

So they are independent from PWD, but without expanding symlinks.

Not all provided CRLs might match the CA, thus use only ones coming from
given CA.

See merge request !13

These scripts automate part of the work needed on the client side of
kedifa:
- retrieving the secret token, storing it along with server authentication
  (CA cert and CRL) paths
- serialising a key and certificate pair the way kedifa expects them, and
  pushing the result to kedifa

 * *: defined encoding on each file
 * app: use b'' or encode before returning with wsgiref
 * cli: switch to binary for files
 * test: decode/b'' or encode when needed

As the servers can take a bit of time before emitting the log entry, wait a
bit before asserting the status.

pylint understands this and does not report errors about accessing
undefined members.

http://pylint.pycqa.org/en/stable/faq.html#how-do-i-avoid-access-to-undefined-member-messages-in-my-mixin-classes

See merge request !11

See merge request !10

caucase.util.load_crl API changed in an incompatible way in caucase 0.9.9 .
This change fixes the API breakage and adds support for mor than one CRL
in kedifa.app.http .

By inserting other CA certificate as first one in the list, the problem is
reproduced in the test.

Depending on the environment, various exceptions can be risen, so be tolerant
regarding the exception type.

/reviewed-on nexedi/kedifa!5