1. 31 Dec, 2018 1 commit
  2. 14 Dec, 2018 1 commit
    • Vincent Pelletier's avatar
      all: Rework logging. · 05893598
      Vincent Pelletier authored
      Make tests almost completely silent by default, while still printing output
      generated during corresponding test on failure.
      Produce more somewhat-apache-like error logs, both from httpd and wsgi
  3. 19 Oct, 2018 1 commit
  4. 26 Sep, 2018 3 commits
    • Vincent Pelletier's avatar
      all: More python3 adaptations. · 8ce08bf9
      Vincent Pelletier authored
      What was not picked up by 2to3.
    • Vincent Pelletier's avatar
      all: Reduce differences with python3. · 7f9e56cf
      Vincent Pelletier authored
      Using only 2to3 conversions which are python2-compatible.
    • Vincent Pelletier's avatar
      all: Make caucased https certificate independent from CAS. · 17325dc0
      Vincent Pelletier authored
      This is a step in the direction of being browser-friendly: if caucased
      https certificate is issued by CAS CA, then for a browser to trust that
      certificate it would have to trust all certificates emitted by CAS CA
      certificate. This would be very dangerous, as CAS CA does not constrain
      the certificates it may sign, so it exposes users of that caucased to
      rogue certificates.
      Alone, this step is insufficient, as the new internal "http_cas" does not
      constrain certificates yet. This will happen in a separate commit, to
      ease review and regression testing.
      As a consequence of this step, by default client will not check server
      certificate in https. This is consistent with how trust is bootstrapped
      with plain http: maybe client is accessing an unexpected/malicious
      caucased, but in such case issued certificates will be worthless to a
      party which could access the correct caucased. Also, the client
      certificate presented to caucased does not allow that caucased to fake
      being that user, so there is no privilege escalation possible for
  5. 22 Jul, 2018 1 commit
  6. 12 Jul, 2018 2 commits
    • Vincent Pelletier's avatar
      Bump copyright. · 94146872
      Vincent Pelletier authored
    • Vincent Pelletier's avatar
      TODO: Update. · b1e05975
      Vincent Pelletier authored
      pyca/cryptography 21st release is out and caucase already requires
      Also, literal IPv6 CRL distribution points do not fail anymore - add test.
      No more known 1.0 blockers ! Weee !
  7. 04 Nov, 2017 1 commit
  8. 03 Nov, 2017 1 commit
  9. 21 Oct, 2017 1 commit
  10. 20 Oct, 2017 1 commit
  11. 23 Aug, 2017 1 commit
    • Vincent Pelletier's avatar
      all: Major rework. · ecd07d22
      Vincent Pelletier authored
      - Re-evaluate feature set and REST API.
      - switch duration units to days, which are more meaningful than sticking to
        ISO units in this context.
      - Implement the "cau" half of "caucase".
        As a consequence flask password authentication mechanism is not needed
        anymore. As HTML UI is not required internally to caucase, and as
        sqlalchemy is not used to its full extend, get rid of these
        dependencies altogether.
      - Implement REST HTTP/HTTPS stand-alone server as a layer above WSGI
        application, and integrate HTTPS certificate issuance and renewal
        mechanism to simplify deployment: no middleware needed, so from
        gunicorn dependency.
      - Use standard python modules for http client needs.
      - Re-evaluate data retention options:
        - unsigned CSRs are kept forever
        - CRTs are stored in CSR table, and a 24 hour expiration is set
        - CA CRTs: (unchanged, expire when past validity period)
        - CRLs: (unchanged, expire when past validity period)
      - Redispatch housekeeping tasks:
        - CA renewal happens when caucase is used and renewal is needed
        - CRL is flushed when re-generated
        - CSR table (containing CRTs) is cleaned when a new CSR is received
        removing completely the need for these special periodic tasks.
      - Storage parameters are not stored persistently anymore, instead their
        effect (time offsets) is applied before storing (to protect against
        transient retention period reconfiguration from wiping data).
      - Rework storage schema.
      - Implement certificate extension propagation & filtering.
      - Implement "Certificate was auto-signed" extension.
      - More docstrings.
      - Use a CSR as a subject & extensions template instead of only allowing
        to override the subject. Useful when renewing a certificate and when
        authenticated client wants to force (ex) a CommonName in the subject.
      - Reorganise cli executable arguments to have more possible actions.
        Especially, make CA renewal systematic on command start (helps
        validating caucase URL).
      - Increase the amount of sanity checks against user-provided data (ex:
        do not upload a private key which would be in the same file as the CRT
        to renew).
      - Extend package classifiers.
      - Get rid of revocation reason, as it seems unlikely to be filled, and
        even less likely to be read later.
      - (almost) stop using pyOpenSSL. Use cryptography module instead.
        cryptography has many more features than pyOpenSSL (except for certificate
        validation, sadly), so use it. It completely removes the need to poke
        at ASN.1 ourselves, which significantly simplifies utils module, and
        certificate signature. Code is a bit more verbose when signing, but much
        simpler than before.
      - add the possibility to revoke by certificate serial
      - update gitignore
      - include coverage configuration
      - include pylint configuration
      - integrate several secondary command:
        - caucase-probe to quickly check server presence and basic
          functionality, so automated deployments can easily auto-check
        - caucase-monitor to automate key initial request and renewal
        - caucase-rerequest to allow full flexibility over certificate request
          content without ever transfering private keys
      - add a secure backup generation mechanism
      - add a README describing the design
  12. 12 May, 2017 1 commit
  13. 27 Apr, 2017 1 commit
    • Alain Takoudjou's avatar
      initial implementation of certificate authority · 26015ada
      Alain Takoudjou authored
      The certificate authority is used to generate and sign certificate, there is 3 parts:
      - web: which contains API to submit certificate signature request and to download signed certificate
      - cliweb: which is a command line tool used to quickly generate private key and send certificate signature request, he will
      also downlaod automatically the signed certificate as well as ca certificate.
      - cli: is used to garbage collect certificate authority, all expired certificate, csr, crl and revocation will be trashed using this tool.
      The first csr can be automatically signed, the rest will be signed by the adminitrator, first connection to /admin/ will ask to set password
      the admin can see all csr (pending) then sign them. As soon as csr is signed, the client will download (cliweb) the certificate.
      client can also renew or revoke his certificate using CA API. Renew and revoke are immediate, there is no admin approval.
      on server side, the storage storage.py use sqlite to store all informations (certificat, csr, crl and revocations), there is no use of openssl here.
      ca.py will invoke the storage to store or to get certificates.
      the client store certificate directly on filesystem, so it can be read by apache, nginx, etc.