Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • A acme-dns-tiny
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1
    • Issues 1
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Adrien Dorsaz
  • acme-dns-tiny
  • Issues
  • #7
Closed
Open
Created Oct 23, 2018 by Adrien Dorsaz@adrienOwner7 of 11 tasks completed7/11 tasks

v2.1 : Compatibility with current boulder and acme-draft-16

As time go one, new RFCs appeared...

Currently, we have to implement acme-draft-16 (boulder server is already updated, but keep in mind its divergences).

I've noticed these differences:

  • HTTP requests:

    • 6.3. GET and POST-as-GET Requests
      • GET not authenticated: Nonce and Directory (possible for certificate but not mandatory !)
      • POST-as-GET: GET authenticated with payload = "" Check that every GET is replaced by a POST with payload = "" (non-JSON !)
  • Request Verification:

    • requires now to send an empty body payload = "{}"
  • Account rollover:

    • Old / New key signatures has been inverted (since draft 13)

      To change the key associated with an account, the client sends a constructs a key-change object describing the change that it would request to the server containing signatures by both the old and new like the server to make: keys. The signature by the new key covers the account URL and the old key, signifying a request by the new key holder to take over the account from the old key holder. The signature by the old key covers this request and its signature, and indicates the old key holder's assent to the roll-over request.

    • must remove nonce in the inner jwk (at least from 16 and allowed already before)
  • Certificate issuance:

    • Check what appears in the CSR: CommonName and SubjectAltName normally (since draft 13) -> in case of error, order status stay at "ready" state allowing user to rebuild a CSR in compliance with what has been requested by the CA => really needed to manage orders with status "ready" !
    • Check the Accept HTTP Header in request (application/pem-certificate-chain by default)
  • Aside / nice to have

    • would be cool to give caaIdentities to the user if available (so he could install CAA DNS resource) or even install it !
Edited Oct 27, 2018 by Adrien Dorsaz
Assignee
Assign to
Time tracking