New certificates not installed in pfSense GUI
-
With ref to issue# 18977
I can now renew certificates (although I have to manually trigger a secondary update, which I will hopefully be able to sort out soon as well), but the certificates are not installed in the GUI. They just stay on /tmp/acme/<certname>.
I manually upgraded amce.sh to V 3.1.0 to get the fix for MailInaBox's API change.
Is there something special that the pfSense acme package does that I removed in inadvertently in the process (that I need manually put back)?
-
It looks like acme.inc is the pfSense component, but why does it not get loaded and do it's work?
-
I see the acme_command.sh includes acme.inc.
In acme.inc I see a function "function acme_write_certificate($certref)" and more, so these should be called, but they're not it seems.
Where can I look for the missing piece of the puzzle?
-
@lifeboy said in New certificates not installed in pfSense GUI:
Where can I look for the missing piece of the puzzle?
Probably because
@lifeboy said in New certificates not installed in pfSense GUI:
I have to manually ...
you are in manual mode ? (
).
Finish manually !
( as I presume half-mode doesn't exist )The update (dns_api) method you chose has to be set up correctly ones. From then on, its like you pressed on the autopilot button in a plane : ones set up ok, it works.
Get the 'auto mode' working, and you'll never look back.
I guess that :
when Cron mode (== auto) mode is set up, the certs are renewed by the function that also writes out the obtained certs to the pfSense Cert store.
@lifeboy said in New certificates not installed in pfSense GUI:
Is there something special that the pfSense acme package does that I removed in inadvertently in the process (that I need manually put back)?
euh ... how do I (we) know what you did or remove ?
Afaik : This is the default action list :
as the pfSense GUI (that I use) use the cert that the pfSense GUI web server uses.
Certs will be written to the cert store, no matter what. In Cron mode, that is.
edit :
These : Green :
are the offcial acme files.
The rest is pfSense GUI "glue scripts" , as acme is a CLI tool only, and pfSense is not. -
@Gertjan, "manually" referred to the process of getting the secondary propagated once I pressed to the "issue/renew" button in the pfSense GUI... However, I found the reason why the secondary was not updating and fixed that.
I think I understand the pfSense glue scripts' role and I didn't change any of those. I simply replaced acme.sh and dnsapi/dns_miab.sh with the newer versions.
However, using the testing / staging servers (which I am doing now) doesn't create actual certificates, correct? So I have to wait another 3 or 4 days before I attempt an actual new certifcate issuance, since I ran into the rate-limiting on the production LE servers. :-)
I'll report back when I have tried it again.
-
The staging / test LE servers have no rate limiting - see documentation, LE for this.
@lifeboy said in New certificates not installed in pfSense GUI:
However, using the testing / staging servers (which I am doing now) doesn't create actual certificates, correct?
I'm not sure - I think they do.
Staging uses the same process, only the certs created are signed by a CA that is "unknown" so not trusted.
Afaik, the results are still treated the same as the 'real' certificates.
The last time I used the staging process, I was using "acme.sh" on the command line, on a debian CLI-only server, so not on pfSense. And that's nearly a decade ago.@lifeboy said in New certificates not installed in pfSense GUI:
I simply replaced acme.sh ....
Better double check if jimp (the author of he package) didn't apply changes to the original acme.sh after pulling it from github.
Or maybe he uses the official acme.sh FreeBSD package as a basis, and changed 'things'.A file like "dnsapi/dns_miab.sh" only contains two exported functions, for the add and the remove, and can be copied without much risk.
