Report bugs to unifi deploy hook #3359
Comments
Neilpang
added
the
3rd party api
|
just curious tho this might not be related purely to the unifi deploy hook (first time using acmesh, used certbot before) but i couldn't find something on that matter: does the cronjob that comes with acme is also deploying the certs? |
|
@blackjack4494 yes, acme.sh saves your deploy-hook settings, and re-deploys with those same settings after a successful cron certificate renewal. (This applies to all deploy hooks, not just unifi.) |
|
I'm just replacing an Ubuntu 16.04 VM running Unifi with a new VM running 22.04. When trying to use the unifi hook (which worked great on 16.04), I get I can run
and see 1 existing certificate in the keystore (either providing no password or the default one in the script). I wonder if this relates to it as it mentions Ubuntu Jammy (which is v22) but I'm unsure if I can add the -legacy parameter in the script and if, so where. |
|
I realised the topkcs routine called in unifi.sh lives in the main acme.sh file, so I added -legacy to the first call in that (line 1427 on my system). That line now reads:
And the import now works. |
|
@SupersixEvo thanks for tracking this down. @Neilpang this affects |
|
@medmunds add one more parameter to the in the deploy hook, invoke it with value |
|
also, you should check if current openssl supports "-legacy" option first. |
Can confirm that this works, though my openssl does not accept -legacy directly? |
|
I had a problem with a CloudKey G2+. The deploy script seemed to think it was a Gen1, so deployment failed. The script was looking for /etc/ssl/private/cloudkey.key to identify it as a G1, and that file did exist but was > 2 years old. I wonder if it used to use nginx before it upgraded itself to use Unifi OS. and then the deploy ran fine. |
|
Just to add a +1 to robinalden's comment above. My CloudKey2 was upgraded from UnifiOS 1 --> 2.x --> 3.x and I had exactly the same issue with the deploy hook until I renamed /etc/ssl/private. Perhaps there is a better way to detect the OS version? |
|
from unifi-utilities case "$(ubnt-device-info firmware || true)" in |
|
Not strictly a deploy issue, but ECC certs borked unifi-core on my CloudKey Gen2 Plus running firmware v3.1.13. Blew away the ECC certs, reissued RSA certs, and redeployed to fix. |
|
There should be a status check var. You're assuming we're (FreeBSD) using systemd. The same for the other systectl usage. |
|
I found I had trouble deploying my certs on my UDR running Unifi OS (3.1.16). It seems I'd fall foul of this line as for some reason I had a keystore file at From a bit of searching around it seems that the guest hotspot portal (which I have enabled) may use the I ended up hacking the deploy hook to avoid running the |
|
Trying this on a Unifi Express ... wish me luck! == will delete this comment if no issues No keytool (line 103) on Unifi Express. Wonder what they use? Asked in the community over there, see if I get a response. https://community.ui.com/questions/Keytool-alternative-on-UniFi-Express/5154559a-b064-4f41-a183-a106b9e690dc |
|
We need a check for keytool and if it does not exist use openssl. |
Running a Unifi Dream Machine with the same poblem. I'm not sure openssl can create a Java keystore. You'll notice that the java binaries are also removed. I got my response from Ubiquiti support yesterday, told me SSL isn't their problem. Hacky fix is just to reinstall keytool: apt update && apt install openjdk-11-jre-headless -y puts it in place with a few other packages that seem harmless enough. YMMV with support on that, and likely need to re-run after an update. openjdk-17 is newer, but loads a lot more packages. There's also a minor problem with the UDM running hotspot portal. I need to redeploy a few times to see what's going on, but I think the keystore shouldn't have the CA as well. Error in the log is that "2 certificates were found, only 1 expected." Manually creating the keystore fixes it. |
|
Once the keytool problem is sorted and the certificates correctly converted to a JKS keystore, the next problem is that the default Unifi console uses weak ciphers that aren't compatible with the default RSA certificates from letsencrypt. The system configuration needs to be updated for hotspot portal (and potentially other services to work.) |
|
I recently updated my CloudKey G2 to After getting the certs issued and running this hook, I could see /data/unifi-core/config/unifi-core.key and unifi-core.crt update at first, but when the unifi service restarted, both files were replaced with self-signed RSA certs. I noticed that the certs getting wiped out were ECC, which seemed new with this version of acme.sh. After fiddling with some different options, issuing with |
Openssl can create a java compatible keystore. If fact you should be using it instead of keytool these days for acme.sh. The instructions are here https://docs.oracle.com/cd/E19509-01/820-3503/ggfhb/index.html Modern java implementations are moving away from the old proprietry keystore format to the new pkcs12 format which is the type openssl can create. Example below. The alias should be the same as the one it uses now for the current certificate and key in the keystore. You cannot use this to update a keystore, only create it. Please note a password is mandatory for it to be a java compatible keystore. $ cat mykey.pem.txt mycertificate.pem.txt>mykeycertificate.pem.txt
$ openssl pkcs12 -export -in mykeycertificate.pem.txt -out mykeystore.pkcs12
-name myAlias -noiter -nomaciter |
It looks like you're correct. Every implementation of this Unifi certificate installation was converting to PKCS12 and then importing that to JKS. All the historical documents I could find from Unifi have that as the process as well. I just re-deployed, skipping the JKS import, and it handles the pkcs12 just fine. |
|
Fantastic! Does that mean we have solved the problem? That would be a great outcome! Can you send me links to the historical documents? I am itching to use this on my UX. Happy to drop in a patched unifi deploy hook to test for here then I can write it up. You guys have a wiki or a pages site for this place? |
|
Potentially. Tested on a UDM (not the UDM Pro), and don't have any other devices to test with. Welcome to take a look at my updates: Here's where I am with it: I also had to change the logic for service restart. If unifi is running while unifi-core restarts, it throws an error: This seems to break both wifiman and the hotspot portal, but I don't use wifiman. The hotspot portal now works, but you have to turn encryption off and back on after deploying a new cert for some reason. That's not a new bug though. |
|
Hey all: I no longer own a working CloudKey, so can't really provide support for the unifi deploy hook. (Also, I didn't create it—I just fixed a bug and opened this issue.) If something's broken and you're able to fix it, please open a PR. And mention #3359 in your PR comments so it shows up here. Neilpang (the acme.sh creator/maintainer) has been really responsive about merging fixes while maintaining high project quality. (Especially considering the huge number of PRs this project gets.) But Neil also doesn't run Unifi, so the folks here that are using it will need to make sure proposed fixes work for all the versions of CloudKey and self-hosted Unifi Controller the unifi deploy hook supports. If anyone is able to help with unifi deploy hook maintenance and wants to be on the "assignees" list for this issue, let Neilpang know. (I've removed myself as the assignee.) Also, if the unifi deploy hook doesn't meet your needs, there are a couple of alternatives depending on your setup:
|
|
Found a patch to unifi.sh tested on UnifiOS 4.0.7 on Cloud Gateway Ultra. Here it is. https://gist.github.com/mry/61125fba7b474c0c61cccc4100dd6e02 |
|
We stumbled upon file permission issues for the keystore. opnsense/plugins#4417 lists a possible solution by adding a chown to the RELOAD variable. A cleaner way would be to have env variables containing the desired owner and do the chown in the deploy script if run as root. Would you be open to this kind of addition? Then I would propose a PR with the required changes. |
|
Gen1 Appliance here (unifi os 4.1.9), updated to acme.sh v3.1.0 , cert renew didn't work first time to fix....
|
|
I've been running into trouble lately with this deploy script on my Cloud Key Gen2+ running Unifi OS 4.1.9, Network 8.6.9. The cert/key I'm trying to deploy are 2048-bit RSA. Output of |
There's a potential fix for this in my fork, but since I don't have a Cloud Key, I can't test it, and I don't want to pull an untested fix upstream. You're welcome to give it a shot and I can pull request if it works. |
|
Your branch of the deploy script worked. There were some errors reported in the output: But as you see, it ultimately reported success and the cert was deployed. |
This is exactly why I don't want to merge without testing. The original code tars the certificates. I'm not sure if it's for backup or because the cloudkey needs it. One of the variables wasn't referenced correctly. My fork should be fixed now, if anyone with a CloudKey wants to test it. |
Works for me with a Cloud Key gen 2! |
|
Hi all, trying to get a cert on my self-hosted system running on Debian 12. Have tried everything in this thread, last resort was the generate the key (letsencrypt) using the -k 2048 option. My keystone is in the correct location for a standard install:
Have tried editing the unifi.sh to point at both, same result every time. Here is the debug output.... I'm out of ideas that this point, if someone can help, please. |
You are setting DEPLOY_UNIFI_KEYSTORE to an invalid location. It either doesn't exist, is not a file (a directory or maybe symlink?) or else you don't have permission to it. |
|
Thanks for the push in the right direction. I changed the permissions to 777 for the keystore and the directory and that did the trick. The reason I hesitated do that was the impression that the script did not want one to make all those changes. |
It assumes you're running the script as root, in which case the permissions shouldn't matter. 777 is bad, especially for something like a keystore. The file needs to be readable by whatever user the unifi services are running under, and writable by whatever user you're running acme.sh as. |
|
I tried rolling back (it's installed in a VM) and installing it as root yesterday. However there was another issue that I didn't write down when I ran the script to create the certificate. It works for now, I will adjust the permissions. Thanks again |
|
when i use the deploy hook on unifi dreamwall after the |
I'm experiencing the same issue on a UniFi Cloud Key Gen2 Plus (UniFi OS 4.1.22). |
|
After reverse engineering Using I fixed it was to append the following to (Update example.com to be your domain). The NODE_EXTRA_CA_CERTS environment variable tells NodeJS which CA to use. |
Oh cool, this can work to use ECC certs. Otherwise just issue your cert using -k 2048 as described above. |
|
Brilliant work. So it’s a CA cert issue, amazing. Hope that Ubiquti roll
out a fix for the cert shortly.
…On Sun, 20 Apr 2025 at 4:48 am, 3VAbdAVE ***@***.***> wrote:
After reverse engineering unifi-core which is a NodeJS app (
/usr/share/unifi-core/app/service.js), it seems the generated Lets
Encrypt cert cannot be loaded by tls.createSecureContext() so the service
regenerates a self-signed cert.
Using openssl it seems the CA isn't bundled with the OS (I'm not familiar
with the CA certificate history of Lets Encrypt certs, has the CA recently
been updated?).
I fixed it was to append the following to /etc/default/unifi-core:
NODE_EXTRA_CA_CERTS="/root/.acme.sh/example.com_ecc/ca.cer"
(Update example.com to be your domain).
The NODE_EXTRA_CA_CERTS
<https://nodejs.org/docs/latest-v18.x/api/cli.html#node_extra_ca_certsfile>
environment variable tells NodeJS which CA to use.
Oh cool, this can work to use ECC certs. Otherwise just issue your cert
using -k 2048 as described above.
—
Reply to this email directly, view it on GitHub
<#3359 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJYYSIQUWBAUFDKT7RAHHVL22KK7HAVCNFSM4V6KYXQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEOBRGY4DEMZQGUYQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
*3VAbdAVE* left a comment (acmesh-official/acme.sh#3359)
<#3359 (comment)>
After reverse engineering unifi-core which is a NodeJS app (
/usr/share/unifi-core/app/service.js), it seems the generated Lets
Encrypt cert cannot be loaded by tls.createSecureContext() so the service
regenerates a self-signed cert.
Using openssl it seems the CA isn't bundled with the OS (I'm not familiar
with the CA certificate history of Lets Encrypt certs, has the CA recently
been updated?).
I fixed it was to append the following to /etc/default/unifi-core:
NODE_EXTRA_CA_CERTS="/root/.acme.sh/example.com_ecc/ca.cer"
(Update example.com to be your domain).
The NODE_EXTRA_CA_CERTS
<https://nodejs.org/docs/latest-v18.x/api/cli.html#node_extra_ca_certsfile>
environment variable tells NodeJS which CA to use.
Oh cool, this can work to use ECC certs. Otherwise just issue your cert
using -k 2048 as described above.
—
Reply to this email directly, view it on GitHub
<#3359 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJYYSIQUWBAUFDKT7RAHHVL22KK7HAVCNFSM4V6KYXQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEOBRGY4DEMZQGUYQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I have this issue too. Cloud Key Gen 2 plus. UniFi OS 4.1.22. How do I do the Running this commands manually gets the correct certificate: |
That's because nginx is ok with the ECC certs. The Unifi controller's Java software doesn't seem to like them. Has anyone tested that all the features work with this, or just the web interface? Delete the certificate from your .acme.sh folders, then re-issue your certificate with "-k 2048" to avoid an ECC certificate, and it seems to work automatically. |
Which command do you add the -k 2048 too? |
acme.sh --issue -d example.com -w /home/wwwroot/example.com -k 2048 |
|
Adding "-k 2048" to acme.sh --issue worked for me. 👍 |
|
What does adding -k 2048 actually do to how it’s created? I know its key size but there it more to it I believe.
Get Outlook for Mac <https://aka.ms/GetOutlookForMac>
From: Sam ***@***.***>
Date: Tuesday, 29 April 2025 at 1:36 am
To: acmesh-official/acme.sh ***@***.***>
Cc: Kevin Davies ***@***.***>, Comment ***@***.***>
Subject: Re: [acmesh-official/acme.sh] Report bugs to unifi deploy hook (#3359)
[https://avatars.githubusercontent.com/u/1038277?s=20&v=4]samboman left a comment (acmesh-official/acme.sh#3359)<#3359 (comment)>
Adding "-k 2048" to acme.sh --issue worked for me. 👍
—
Reply to this email directly, view it on GitHub<#3359 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJYYSIWQH6N4DIAT4LYXPTL23ZDIHAVCNFSM4V6KYXQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEOBTGU3DMMZYGQ3A>.
You are receiving this because you commented.
|
It's the key size and, by necessary implication, the type of key. A 2048-bit key can only (in acme.sh) be an RSA key. Otherwise, it's going to default to using an ECC key. And lots of systems still can't deal with ECC keys. |
Thank you. |
|
I had certificates already. After some searching I figured if I put them in ~/.acme.sh/domain_ecc/ then acme would find them. Then through trial an error figured out the default filenames and renamed what I had.
Tested on a Unifi Gateway Ultra running
Tested on same Unifi Gateway Ultra running
Took significantly longer to restart my guess is its rejecting the new certificate. When I open a browser to the device it continues to show the old certificate and not the new one. I've dumped the keystore and the certs in it are correct. So where are the UI certs being stored? |
|
Edit: I found them stored in /data/unifi-core/config/b8d5ef93-0d86-470f-9a22-5a90c8b16c9f crt and key file. # pwd
/data/unifi-core/config
# grep activeCert settings.yaml
activeCertId: b8d5ef93-0d86-470f-9a22-5a90c8b16c9fx
# openssl pkey -in b8d5ef93-0d86-470f-9a22-5a90c8b16c9f.key -text_pub -noout
Public-Key: (256 bit)
pub:
04:0b:0c:e7:a2:c4:a9:36:ba:f8:0c:f1:da:39:a8:
37:56:8d:53:1e:ff:64:f5:ce:3b:81:c5:5e:fe:1e:
72:59:e2:f8:98:38:8d:2f:27:16:00:a2:24:5e:65:
62:41:c7:3a:06:f5:d4:d9:ce:d6:8b:ca:97:f1:46:
63:5e:93:c0:f4
ASN1 OID: prime256v1
NIST CURVE: P-256
# openssl x509 -in b8d5ef93-0d86-470f-9a22-5a90c8b16c9f.crt -noout -text | head -22
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:64:94:b4:1e:d6:56:a3:34:8c:96:4c:bf:d3:09:4f:5b:88
Signature Algorithm: ecdsa-with-SHA384
Issuer: C = US, O = Let\'s Encrypt, CN = E5
Validity
Not Before: Jan 29 10:32:44 2025 GMT
Not After : Apr 29 10:32:43 2025 GMT
Subject: CN = *.f5traffic.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:0b:0c:e7:a2:c4:a9:36:ba:f8:0c:f1:da:39:a8:
37:56:8d:53:1e:ff:64:f5:ce:3b:81:c5:5e:fe:1e:
72:59:e2:f8:98:38:8d:2f:27:16:00:a2:24:5e:65:
62:41:c7:3a:06:f5:d4:d9:ce:d6:8b:ca:97:f1:46:
63:5e:93:c0:f4
ASN1 OID: prime256v1
NIST CURVE: P-256
root:/data/unifi-core/config#
# openssl x509 -pubkey -in b8d5ef93-0d86-470f-9a22-5a90c8b16c9f.crt -noout | openssl md5 ; openssl pkey -pubout -in b8d5ef93-0d86-470f-9a22-5a90c8b16c9f.key | openssl md5
(stdin)= c98b7889db9f35f2d4a31e11f5f563a7
(stdin)= c98b7889db9f35f2d4a31e11f5f563a7
#
If I change the settings.yaml to use any other certs including the new ones it unifi-core fails to start. The existing ones which expire today work perfectly fine. The existing is an EC cert. I am not sure why the new one will not successfully get used. |
and others
This is the place to report bugs in the unifi deploy hook.
If you experience a bug with
--deploy-hook unifi, please report it in this issue. (Please include the--debugoutput to assist in diagnosing any problems.)Thanks!
The text was updated successfully, but these errors were encountered: