1. 16 Aug, 2019 1 commit
  2. 04 Jul, 2019 1 commit
  3. 21 Jun, 2019 1 commit
  4. 11 Jun, 2019 2 commits
  5. 07 Jun, 2019 1 commit
  6. 02 Jun, 2019 1 commit
  7. 06 Sep, 2017 2 commits
  8. 31 Aug, 2017 1 commit
  9. 29 Aug, 2017 2 commits
  10. 15 Aug, 2017 1 commit
  11. 14 Aug, 2017 2 commits
  12. 11 Aug, 2017 2 commits
  13. 01 Jun, 2016 1 commit
  14. 16 May, 2016 1 commit
  15. 27 Apr, 2016 1 commit
  16. 22 Jan, 2016 1 commit
    • Patrick J Cherry's avatar
      common: Refactored how --force works and when certs get generated/rolled over · ddc32981
      Patrick J Cherry authored
      The defaults are as follows:
      
      * If the current set is available
      
      ** If it is due to expire inside the threshold
      
      *** generate a new set if there is no set more recent (unless instructed
      otherwise)
      *** roll over to the new set if one has been generated (unless
      instructed not to)
      
      ** Otherwise
      
      *** do not generate a new set (unless instructed otherwise)
      *** do not roll over (unless instructed to)
      
      * If the "current" set is missing, but other sets are available
      
      ** If the most recent set is due to expire inside the threshold
      
      *** generate a new set (unless instructed otherwise)
      *** roll over to the new set if one has been generated (unless
      instructed not to)
      
      ** If the most recent set is not due to expire soon
      
      *** do not generate a new set (unless instructed otherwise)
      *** roll over to the latest set (unless instructed not to)
      
      * If there are no certificate sets
      
      ** generate a new one (unless instructed otherwise)
      ** roll over to the new set if one has been generate (unless instructed
      not to)
      ddc32981
  17. 21 Jan, 2016 1 commit
  18. 14 Jan, 2016 1 commit
  19. 11 Jan, 2016 1 commit
  20. 08 Jan, 2016 2 commits
    • Patrick J Cherry's avatar
      common: Massive commits suck · 764ebd54
      Patrick J Cherry authored
      * Refactored symbiosis-ssl code into the library
      * Added tests to test this new code.
      * symbiosis-ssl tries to regain privs after creating the certs if it
        thinks it has them.
      * Changed what gets logged when a bit.  Stuff in the SSL validation
        checks is now only shown if $DEBUG is set.
      * The cache of available SSL sets is always emptied before rollover
        starts.
      * The way available sets are sorted has changed to be done by expiry.
      * The symlink to current now uses the full path.
      * SSL sets are now kept in config/ssl/sets for neatness/namespace
        goodness.
      * CertificateSet#write drops privs if possible when creating a new set.
      764ebd54
    • Patrick J Cherry's avatar
      721651de
  21. 07 Jan, 2016 2 commits
    • Patrick J Cherry's avatar
      4d6a0bf2
    • Patrick J Cherry's avatar
      common: LetsEncrypt registration for a key now tested with an auth request · 69597bf7
      Patrick J Cherry authored
      There is no way to determine if an key is already registered with the
      server.  Previously we just registered and caught any errors, but it
      turns out that the Acme servers always return "Malformed" if there is
      any problem with the request at all (e.g. bad email address, key
      previously registered).  This means we can return a sane error to the
      user if the request fails, without parsing the error text.
      
      However if a key is not registered, the server will return Unauthorized
      when requesting a new challenge via new-authz, so we can use that to see
      if a key is valid or not.
      69597bf7
  22. 06 Jan, 2016 1 commit
  23. 04 Jan, 2016 1 commit
  24. 14 Dec, 2015 2 commits