ACME - Renewal number of days not yet reached



  • Hi guys,

    in our company's infrastructure we automate certificate distribution across servers and services both win and linux but we got a bad starting point since launching /usr/local/pkg/acme/acme_command.sh "renewall", by cron or even manually, we always receive "Renewal number of days not yet reached".

    As you can see in the attached file a certificate expired yesterday and another one expired today. We were able to renew manually these certs from pfsense UI > Acme package, using issue/renew button.

    Acme package version 0.1.23

    Thanks in advance for any help




  • Hi,

    First what versions ? pfSense / acme

    Issue/Renew manually - and then have a look at the generated log file.

    Remember : you don't have to wait the entire renewal period. After setting up an account, and hitting "Issue", you can repeat the "Issue" a couple of minutes later. There is of course a limit of 5 a day or something like that.



  • Hey Gertjan,

    i did not notice my sign was no more there. Anyway we are on 2.4.2-RELEASE (amd64) and ADI_RCCVE-01.00.00.17-nodebug as coreboot. As already wrote Acme package version is 0.1.23.

    Using pfsense webui and pressing button there are no issue at all: certificates are always updated (with daily limit).

    On the contrary acme_command.sh do not update outdated certs.

    Logs in \tmp\acme\ are only created when procedure get an outdated cert and it seems it does not write any system log (in any case?).




  • @nagaraja:

    ….
    As already wrote Acme package version is 0.1.23.

    You should read this Topic: ACMEv2 is live!  (Read 1132 times)
    0.1.24 and 0.1.25 exist.
    acme is bleeding edge technology. Always use the latest version …. and still, lighting up some candles is advisable.

    @nagaraja:

    Using pfsense webui and pressing button there are no issue at all: certificates are always updated (with daily limit).

    Something is very wrong then.
    My cert dates from … 3 days before - a new wild card cert - I consider it old already  ;)
    When I hit Issue, I will get a new one - and a (huge) log is created, no matter what.

    I advise you to ditch all settings, and restart.

    I just tried it - hitting Issue again :

    V2_brit-hotel-fumel.net
    Renewing certificateaccount: V2_brit-hotel-fumel.net
    server: letsencrypt-production-2
    
    /usr/local/pkg/acme/acme.sh --issue -d 'brit-hotel-fumel.net' -d '*.brit-hotel-fumel.net' --home '/tmp/acme/V2_brit-hotel-fumel.net/' --accountconf '/tmp/acme/V2_brit-hotel-fumel.net/accountconf.conf' --force --reloadCmd '/tmp/acme/V2_brit-hotel-fumel.net/reloadcmd.sh' --dns 'dns_nsupdate' --dnssleep '60' --log-level 3 --log '/tmp/acme/V2_brit-hotel-fumel.net/acme_issuecert.log'
    
    Array
    (
    [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
    [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
    [NSUPDATE_SERVER] => /tmp/acme/V2_brit-hotel-fumel.net/brit-hotel-fumel.net/nsupdate
    [NSUPDATE_KEYNAME] =>
    [NSUPDATE_KEYALGO] => 157
    [NSUPDATE_KEY] => /tmp/acme/V2_brit-hotel-fumel.net/brit-hotel-fumel.net/nsupdate
    )
    [Wed Mar 21 18:12:24 CET 2018] Multi domain='DNS:brit-hotel-fumel.net,DNS:*.brit-hotel-fumel.net'
    [Wed Mar 21 18:12:24 CET 2018] Getting domain auth token for each domain
    [Wed Mar 21 18:12:29 CET 2018] Getting webroot for domain='brit-hotel-fumel.net'
    [Wed Mar 21 18:12:30 CET 2018] Getting webroot for domain='*.brit-hotel-fumel.net'
    [Wed Mar 21 18:12:30 CET 2018] brit-hotel-fumel.net is already verified, skip dns-01.
    [Wed Mar 21 18:12:30 CET 2018] *.brit-hotel-fumel.net is already verified, skip dns-01.
    [Wed Mar 21 18:12:30 CET 2018] Verify finished, start to sign.
    [Wed Mar 21 18:12:33 CET 2018] Cert success.
    -----BEGIN CERTIFICATE-----
    MIIGIzCCBQugAwIBAgISA2YkH9JCB8jViSlVXZ+SoNpxMA0GCSqGSIb3DQEBCwUA
    MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
    ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAzMjExNjEyMzFaFw0x
    ODA2MTkxNjEyMzFaMB8xHTAbBgNVBAMTFGJyaXQtaG90ZWwtZnVtZWwubmV0MIIC
    IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAurojE3CuExlNllbxz04ALLg2
    fEF92FzVkxbnHkYfaRta7OlHu/9GNCD2XlpoAWmFuci3Gz7L8jL0f+bhLueXJTN7
    T5nPMlKekglU4cw6mXGSwKuQe2O/tDNkCRMyfcbvK0ZPoz0+b0cV99g8AOmDYCPT
    N09scza5SAF42A5Y7CPbnSIrYRNuROmPl1wI9zdxfhJod7F+ICFgSYMwgUhxApqF
    RwBuRhZyN08120sNV2IdD9S+dJoVYGMAgosEoWHj5TrbIIvHHwGilOfm8iK9o/o1
    YEmFntEgr5HO5zRhZXud1UNZknkhPZz3RJCQ00AeMPBz4B7FM+iuBAVR7xoMAdEx
    0poNUBD8LcKhK7dR/0qAApPa8Xp7ECpGRJuwnN2y4mjgOAZZCYFA5Huit5Vf/SO6
    HDEGMn6i7n8ISvwBPNwt4oTo111sZDfBT7kKkHacob9Dz13IcosdeFG/Yl6ULahm
    SpgGocTeEv8KGffdPJa++5suI+bOihu63qycmJzRYGRneeQz52nImHjEbAMe/UDq
    DLpvvS0jKcaXobkZlJcvzyLopaYgsDYDIlRcYskZmsVYsTJfur0hZwOjm7DbzzWG
    YVQCziyX1TWV28CAPN7u0s/chHcxGsT5JmxQkyX2W/aA6pC60deTB40zyw1F1GlE
    K7Lgmc2DfJlnvaB4M+MCAwEAAaOCAiwwggIoMA4GA1UdDwEB/wQEAwIFoDAdBgNV
    HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
    FgQUoCvGNtTQayc6/hVMu6/QXXijiyQwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3
    pkVl7/Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2Nz
    cC5pbnQteDMubGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2Vy
    dC5pbnQteDMubGV0c2VuY3J5cHQnLzA3BgNVHREEMDAughYqLmJyaXQtaG90
    ZWwtZnVtZWwubmV0ghRicml0LWhvdGVsLWZ1bWVsLm5ldDCB/gYDVR0gBIH2MIHz
    MAgGBmeBDAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEWGmh0dHA6
    Ly9jcHMubGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1RoaXMgQ2Vy
    dGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWluZyBQYXJ0
    aWVzIGFuZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlmaWNhdGUg
    UG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3JlcG9zaXRv
    cnkvMA0GCSqGSIb3DQEBCwUAA4IBAQADZpsMCvE1UotGQwd+vla06arIXcuzJ1RW
    VJUc89HLhHPL+K1OWQ8kDu28quS9AlDpS/ZU5T9Rk1MMSU5lWgRqrtuQf10Sjzoz
    eKqiEZAJvRrQVurQy361yw0dgxc2ggmggq9VQdXpxNst8rrCk+0mcGdoOFCULn7v
    5nz+hQUhwqR/C/sj4NB7brAifDjDL4XRpy5g1dE2qJF5M93jn6FLqkZp9iRMpeTU
    FDkYNvYpKOiwCYhpHCWVBAF9qn/3Irw/VNpmKYRCrlrpZwqUf8OJQ4cEnztuVsDK
    XG9yS0tiZIcqJoiyRPcDSLuNrYEgGG6odGQsLbutKLGZotbqhlq8
    -----END CERTIFICATE-----
    [Wed Mar 21 18:12:33 CET 2018] Your cert is in /tmp/acme/V2_brit-hotel-fumel.net//brit-hotel-fumel.net/brit-hotel-fumel.net.cer
    [Wed Mar 21 18:12:33 CET 2018] Your cert key is in /tmp/acme/V2_brit-hotel-fumel.net//brit-hotel-fumel.net/brit-hotel-fumel.net.key
    [Wed Mar 21 18:12:33 CET 2018] The intermediate CA cert is in /tmp/acme/V2_brit-hotel-fumel.net//brit-hotel-fumel.net/ca.cer
    [Wed Mar 21 18:12:33 CET 2018] And the full chain certs is there: /tmp/acme/V2_brit-hotel-fumel.net//brit-hotel-fumel.net/fullchain.cer
    [Wed Mar 21 18:12:33 CET 2018] Run reload cmd: /tmp/acme/V2_brit-hotel-fumel.net/reloadcmd.sh
    
    IMPORT CERT V2_brit-hotel-fumel.net, /tmp/acme/V2_brit-hotel-fumel.net/brit-hotel-fumel.net/brit-hotel-fumel.net.key, /tmp/acme/V2_brit-hotel-fumel.net/brit-hotel-fumel.net/brit-hotel-fumel.net.cer
    update cert![Wed Mar 21 18:12:33 CET 2018] Reload success
    
    

    This is the small log that shows in the GUI when done.



  • Hey,

    it is clear now that UI button and /usr/local/pkg/acme/acme_command.sh command have different behaviour. Button always renew certificate even if it not outdated. Script always check DateTime. I followed script's code chain and it ends in acme.inc script calling the function issue_certificate and looping for each certificate.

    That's the part

    function issue_certificate($id, $force = false, $renew = false) {
                    $certificate = & get_certificate($id);
                    if (!$force) {
                            if ($certificate['status'] != 'active') {
                                    echo "Certificate renewal for this certificate is set to: disabled\n";
                                    return;
                            }

    $renewafterdays = is_numericint($certificate['renewafter']) ? $certificate['renewafter'] : 60;
                            $timetorenew = false;
                            $now = new \DateTime();
                            $lastrenewal = new \DateTime();
                            $lastrenewal->setTimestamp($certificate['lastrenewal']);
                            $nextrenewal = $lastrenewal->add(new \DateInterval('P'.$renewafterdays.'D'));
                            if ($now >= $nextrenewal) {
                                    echo "## Its time to renew ##\n";
                                    $timetorenew = true;
                            } else {
                                    echo "Renewal number of days not yet reached.\n";
                            }
                    }

    I then updated to lastest package 0.2.5_1

    Checking again that bit of code, there are not any changes.

    Anyway i created a new cert with a time to live of 1 day. Now what i expect is a new cert every day by cron script.

    I'll let you know but i feel few hopes



  • Well, the cron job only renews if the "certificate date" +"Certificate renewal after" < "current date".
    It surely doesn't renew every day.

    As per "Let's Encrypt" house rules, such a cron should run one a day - or even more, and undertake a renewal after +/- 60 days.
    You can choose these "60 days" in the settings.

    Btw : you found the code.
    Add some echo lines, especially where the date from the current cert is extracted and print that.
    Then $renewafterdays  is add, and if the result is should be smaller then the current moment, then renewal proceeds.

    For example : the code is reading/using the 'right' certificate ?



  • Hey,

    i found some interesting stuff applying some echo lines on datetimes:

    • Let's encrypt generated certificate is always 90 days valid

    • pfsense WebUI "Services/Acme/Certificate options/Certificate renewal after" option does not affect certificate lifetime generated by Let's encrypt. It does affect acme_command.sh;

    Even a 1 day certificate is valid for 90 days but the option set "Certificate renewal after" correctly set the end date checked by acme_command.sh. So i trust that it could do a good job within 90 days time frame. Any value grater than 90 would let you drop in an unmanged time frame where your certificate is outdated but the script things "Renewal number of days not yet reached".

    I would suggest a bug fix in pfsense UI to discard bad values set up in certificate edit page and help users.

    Also

    You should consider the second gap: since cron job run once a day, you may run the job just 1 hour before a certificate may ends, then you have to wait next job 24 later to get an updated certificate; in the case a webserver's certificate you can get users warned by browser security features for 23/24 hours.

    We will plan to examine better the code and patch it with such as a provision feature to issue a new certificate if it will be replaced soon

    Easy as we speak

    just adding the following line in acme.inc it is possible to renew certificates on the edge of 24 hours

    $nextrenewalex = $nextrenewal->sub(new \DateInterval('PT24H'));

    in the function issue_certificate right after:

    $nextrenewal = $lastrenewal->add(new \DateInterval('P'.$renewafterdays.'D'));

    With this patch cron job would be more efficent while renewing certificates giving no downtime of services where certificates are applied to


Log in to reply