Renewed acme certificate requires manual restart of webConfigurator



  • Hi,

    I've noticed on all my pfsense 2.4.1 installations that after an acme certificate has been reissued automatically by the plugin, the webserver still deliveres the old certificate until
    I restart the webConfigurator manuall using command 11 on the terminal.

    • Julian

  • Rebel Alliance Developer Netgate

    Did you setup an action on the cert entry in ACME to restart the GUI?



  • AH, thank you, I must have missed that part  ::)

    Btw: Within all my clusters I'm running into a problem with one of them when renewing the certificate:

    
    [Mon Jan 22 16:40:06 CET 2018] original='{
      "identifier": {
        "type": "dns",
        "value": "**********"
      },
      "status": "pending",
      "expires": "2018-01-29T15:40:06.169454005Z",
      "challenges": [
        {
          "type": "http-01",
          "status": "pending",
          "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/**************",
          "token": "************"
        },
        {
          "type": "dns-01",
          "status": "pending",
          "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/***************",
          "token": "***************"
        }
      ],
      "combinations": [
        [
          0
        ],
        [
          1
        ]
      ]
    }'
    [Mon Jan 22 16:40:06 CET 2018] responseHeaders='HTTP/1.1 100 Continue
    Expires: Mon, 22 Jan 2018 15:40:05 GMT
    Cache-Control: max-age=0, no-cache, no-store
    Pragma: no-cache
    
    HTTP/1.1 201 Created
    Server: nginx
    Content-Type: application/json
    Content-Length: 747
    Boulder-Requester: 28046419
    Link: <https: acme-v01.api.letsencrypt.org="" acme="" new-cert="">;rel="next"
    Location: https://acme-v01.api.letsencrypt.org/acme/authz/*************
    Replay-Nonce: ************
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=604800
    Expires: Mon, 22 Jan 2018 15:40:06 GMT
    Cache-Control: max-age=0, no-cache, no-store
    Pragma: no-cache
    Date: Mon, 22 Jan 2018 15:40:06 GMT
    Connection: keep-alive
    '
    [Mon Jan 22 16:40:06 CET 2018] response='{"identifier":{"type":"dns","value":"*************"},"status":"pending","expires":"2018-01-29T15:40:06.169454005Z","challenges":[{"type":"http-01","status":"pending","uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/*************","token":"*************"},{"type":"dns-01","status":"pending","uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/**************","token":"****************"}],"combinations":[[0],[1]]}'
    [Mon Jan 22 16:40:06 CET 2018] code='201'
    [Mon Jan 22 16:40:06 CET 2018] The new-authz request is ok.
    [Mon Jan 22 16:40:06 CET 2018] base64 single line.
    [Mon Jan 22 16:40:06 CET 2018] entry
    [Mon Jan 22 16:40:06 CET 2018] Error, can not get domain token ************
    [Mon Jan 22 16:40:06 CET 2018] pid
    [Mon Jan 22 16:40:06 CET 2018] No need to restore nginx, skip.
    [Mon Jan 22 16:40:06 CET 2018] _clearupdns
    [Mon Jan 22 16:40:06 CET 2018] skip dns.
    [Mon Jan 22 16:40:06 CET 2018] _on_issue_err
    [Mon Jan 22 16:40:06 CET 2018] Please check log file for more details: /tmp/acme/*************/acme_issuecert.log
    [Mon Jan 22 16:40:06 CET 2018] _chk_vlist</https:> 
    

    I'm renewing using the TLS Standalone Server method. Port 443 is open and the client should work like the others. Any clue on why it' still in pending mode?

    • Julian

  • Rebel Alliance Developer Netgate

    @netcore:

    I'm renewing using the TLS Standalone Server method. Port 443 is open and the client should work like the others. Any clue on why it' still in pending mode?

    See https://forum.pfsense.org/index.php?topic=142657.0



  • Thank you, this seems to have done the trick. A little bit of extra work because manual DNS is a pita and the local http server can't bind to port 80 becauase of local running ngix - hence a port forwarding is necessary. Also I didn't think of this thread you've mentioned because some renewals still worked with tls, some others didn't so this made it harder for me to specify an exact error scheme.

    • Julian

Log in to reply