Renewed acme certificate requires manual restart of webConfigurator

netcore

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

jimp

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

netcore

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

jimp

@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

netcore

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