Last time updated?

Gertjan

Didn't had a look myself yet .... but it's there : exactly at 03h16 minutes sharp :

2019-01-25 03:15:54	Cron.Info	192.168.1.1	Jan 25 03:16:00 /usr/sbin/cron[87247]: (root) CMD (/usr/local/pkg/acme/acme_command.sh "renewall" | /usr/bin/logger -t ACME 2>&1)
2019-01-25 03:15:55	User.Notice	192.168.1.1	Jan 25 03:16:00 ACME: Checking if renewal is needed for: V2_brit-hotel-fumel.net
2019-01-25 03:15:55	User.Notice	192.168.1.1	Jan 25 03:16:00 ACME: Renewal number of days not yet reached.

Btw : using an external syslogger.

edit : grepping using the magic word ( = ACME) nailed it in a split second.

chudak

@jimp

Just wondering when I see in logs those entries ("Renewal number of days not yet reached"), can I assume that NAT/FW rule for port forwarding was used and worked successfully?

jimp

No, that is only a local check of the certificate expiration date

chudak

@jimp

so how to enforce real check ? Renew via UI ?

jimp

You can force it via the UI but that won't test your schedule since it's time-based.

There isn't an easy way to test that until it runs again naturally.

You could edit the cron job, add -force to the acme script call parameters, then wait overnight for the schedule to trigger, but that's not ideal either.

chudak

@jimp

What if I lift schedule temporarily and run in command line:

/usr/local/pkg/acme/acme_command.sh "renewall" --force

jimp

Just one dash -force.

If you disable the schedule so the rule is always active, then it should work to test just the renew, but that still doesn't help you test the schedule or the cron job.

chudak

@jimp I realize this. My goal to test an odd port fowarding and it did seem to work.

"Reload success" is this sufficient ?

jimp

If you see the cert in the list with an updated valid/expiration date, then yeah.

chudak

@jimp

Everything looks great and worked as expected.

The only minor note

I ran as:

/usr/local/pkg/acme/acme_command.sh "renewall" -force | /usr/bin/logger -t ACME 2 > & 1

Array
(
    [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
    [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
    [port] => XYZ
    [ipv6] => 
)
...
[Wed Jan 30 10:11:14 PST 2019] Cert success.

However when I filtered FW log for XYZ Destination Port I found nothing.

Odd...

Gertjan

@chudak said in Last time updated?:

However when I filtered FW log for XYZ Destination Port I found nothing.

Same thing for me.
I searched for "Magic Cake" and I didn't find nothing aether.
But I wasn't surprised ....
A firewall logs if you instructed it to log.

chudak

@gertjan said in Last time updated?:

@chudak said in Last time updated?:
Cake" and I didn't find nothing aether.
But I wasn't surprised ....
A firewall logs if you instructed it to log.

what do you mean ? why ?

I do have BTW traffic logging enabled for the FW rule.

Gertjan

In that case, it the LE server comes in to check, the firewall rule that logs should log something.

Another side effect : your cert was renewed - just check the dates of the cert.
Btw : don't do this to often : 5 times in a week and your renewal will be blocked.

chudak

@gertjan said in Last time updated?:

In that case, it the LE server comes in to check, the firewall rule that logs should log something.

Another side effect : your cert was renewed - just check the dates of the cert.
Btw : don't do this to often : 5 times in a week and your renewal will be blocked.

Everything worked perfectly, CA renewed.

No log entry in FW logs, that's all
I thought I saw a commit about Acme and FW logs, but can't find it now... Maybe mistaken

Gertjan

@chudak said in Last time updated?:

Everything worked perfectly, CA renewed.

So you're good !

The acme package is not related to the firewall (rules) what so ever. That's up to you.