Problem with a script in certificate renewal-hook

Support
1

I got an email from one of our nethservers with the following info:

/etc/cron.daily/nethserver-letsencrypt-certs:

deploy-hook command “/etc/letsencrypt/renewal-hooks/deploy/10nethserver” returned error code 1

The reason probably is that I have a script that pushes the certificate to my rooter after the letsencrypt certificate got updated, invoked by /etc/e-smith/events/certificate-update/S80push2router. Executing the script manually, I see: The certificate subject does not match the hostname ourdomain.com.

Can someone please help me find out, what the script is expecting as hostname? I tried to execute the script with ourdomain.com and with all the subdomains included in the certificate too. How would I execute the command that the script is executing to see what it expects as hostname?

Or how could this check of the hostname be removed completely?

2

I deleted lines 42-45 and as it then still complained because of the issuer not being correct, I also deleted 46-49. That way the script successfully imports the certificate to opnsense again. :wink:

3

[s]Deploying to OPNsense shouldn’t take more than a couple of lines:

/usr/local/bin/curl -s -k -u $KEY:$SECRET https://$HOST/api/backup/backup/download \
 -o $PATH/opnsense-config-$(/bin/date +%Y%m%d).xml

[/s]

1 Like
4

Thanks for that one. I’ll stick with the script for now, but could be interesting for future reference :slight_smile:

5

It requires a plugin to give an API method for the backup. And I set up a separate user (and API credentials) whose only permission was to download the config. I have a post somewhere on the OPNsense forum with more detail.

1 Like
6

@danb35

Hi Dan

The API / Instruction you posted were to download the config file from OPNsense.
Elleni needs the opposite, uploading files to OPNsense…

I don’t think the Backup-API will allow this, as this almost needs root access to the SSL certs…

My 2 cents
Andy

1 Like
7

Yeah, you’re right. No idea how I misread that in that way. The obvious and correct answer in that case is to just get the cert on the OPNsense box itself, but I think that’s a discussion we’ve had before.

3 Likes
8

I’d fully agree with you here that using eg a DNS based API would be the cleanest and “proper” solution for OPNsense AND NethServer to get correct LE SSL certs.

But the issue here wasn’t the OPNsense NOT having valid certs, rather the OPNsense wasn’t connecting to NethServer’s AD to retrieve Users (AD-Users!) for OpenVPN…

As is well known among us Nethserverians, NethServer is easy to get fixed with a SSL cert.
But not for the AD part, which will still use a self signed SSL CA… And that is not acceptible for most Java or Perl based stuff…

It “should” work if NethServer’s AD had valid LE SSL certs, which can be done easily enough inside NethServer itself, with a little templating and a programming “hook” in the LE updater script.

Maybe not ALL roads lead to Rome, but there are certainly several routes you can take from A to B. Some prefer the easy route, with less hassles, some prefer the more perillous route. And sometimes it’s not a question of preference or even of choice, but sometimes you just have to make do with what you have!

It’s now almost 1.5 years ago that I helped Elleni get his Proxmox / NethServer / OPNsense network working, in a couple of looooong nights, so I do know his basic setup and requirements… :slight_smile:

My 2 cents
Andy

1 Like
9

And it works very well indeed :smiley:

Everytime the LE cert is updated, by renewal-hook script the new certs get copied with scp to ad container followed by a samba restart via ssh, and then the mentioned script gets executed on opnsense via ssh after copies of the new certs are delivered to the opnsense vm via scp too. I don’t think removing those issuer and hostname checks weaken our setup.

I am very happy with our rocksolid setup and with the great help, I was gifted from this very obliging community!

1 Like