Hi, I followed the instructions in the README, but the ./ubios-cert.sh initial command is crashing with this error:

# cd /mnt/data
# ls -la
total 68
drwxr-xr-x   15 root     root          4096 Nov 17 13:15 .
drwxr-xr-x    4 root     root            45 Sep  9 13:26 ..
drwxr-xr-x    6 root     root          4096 Nov 13  2019 crash-data
drwxr-xr-x   74 root     root          4096 Nov 17 13:14 dpi-tracer
drwxr-xr-x    3 root     root          4096 Nov 17 13:15 log
drwx------    2 root     root         16384 Aug 19  2019 lost+found
drwx------    3 root     root          4096 Dec 20  2021 podman
drwxr-xr-x    2 root     root          4096 Dec 20  2021 ssh
drwxr-xr-x    3 root     root          4096 Nov 17 13:11 system
drwxr-xr--    2 root     root          4096 Oct 17 15:14 traces
drwxrwxrwx    4 root     root          4096 Nov 17 13:15 ubios-cert
drwxr-xr-x    4 root     root          4096 Nov 17 13:01 udapi-config
drwxr-xr-x    2 root     root          4096 Dec 20  2021 ui-db
drwxr-xr-x    3 root     root          4096 Nov 13  2019 unifi-management-portal
drwxr-xr-x    7 root     root          4096 Dec 20  2021 unifi-os
# cd ubios-cert/
# ls -l
total 20
drwxr-xr-x    6 root     root          4096 Nov 17 13:15 acme.sh
drwxrwxrwx    2 root     root          4096 Nov 17 13:12 on_boot.d
-rw-r--r--    1 root     root          2691 Nov 17 13:14 ubios-cert.env
-rwxr-xr-x    1 root     root          7883 Nov 17 13:12 ubios-cert.sh
# ./ubios-cert.sh initial
Adjusted permissions for 'acme.sh'
./ubios-cert.sh: line 140: /etc/init.d/cron: not found
#

I noticed I do have a /etc/init.d/crond file though.

# cat /etc/init.d/crond
#!/bin/sh

[ -f /etc/default/dcron ] && . /etc/default/dcron # sets ${CROND_ARGS}

mkdir -p /var/spool/cron/crontabs /var/spool/cron/cronstamps

case "$1" in
	start)
		printf "Starting cron ... "
		start-stop-daemon -S -q -m -b -p /var/run/dcron.pid --exec /usr/sbin/crond -- -f ${CROND_ARGS}
		echo "done."
		;;
	stop)
		printf "Stopping cron ..."
		start-stop-daemon -K -q -p /var/run/dcron.pid
		echo "done."
		;;
	restart)
		$0 stop
		sleep 1
		$0 start
		;;
	reload)
		cron_file="${2}"
		[ -z "${cron_file}" ] && {
			echo "Parameter 'cron_file' required" >&2
			echo "Example: $0 reload /etc/cron.d/cronfile" >&2
			exit 1
		}
		basename "${cron_file}" >> /etc/cron.d/cron.update
		;;
	*)
		echo "usage: $0 {start|stop|restart|reload [cron_file]}"
		;;
esac

I'm using the Cloudflare API method which works fine when issuing the cert from LetsEncrypt however it stores the the files under the wildcard name including the asterisk - see below (I've replaced my real domain name):

[Sat Dec 17 14:34:20 GMT 2022] Your cert is in: /data/ubios-cert/acme.sh/*.test.abc/*.test.abc.cer
[Sat Dec 17 14:34:20 GMT 2022] Your cert key is in: /data/ubios-cert/acme.sh/*.test.abc/*.test.abc.key
[Sat Dec 17 14:34:20 GMT 2022] The intermediate CA cert is in: /data/ubios-cert/acme.sh/*.test.abc/ca.cer
[Sat Dec 17 14:34:20 GMT 2022] And the full chain certs is there: /data/ubios-cert/acme.sh/*.test.abc/fullchain.cer
New certificate was generated, time to deploy it
cp: cannot stat '/data/ubios-cert/acme.sh/_.test.abc/fullchain.cer': No such file or directory
cp: cannot stat '/data/ubios-cert/acme.sh/_.test.abc/fullchain.cer': No such file or directory
cp: cannot stat '/data/ubios-cert/acme.sh/_.test.abc/_.test.abc.key': No such file or directory
cp: cannot stat '/data/ubios-cert/acme.sh/_.test.abc/_.test.abc.key': No such file or directory

The copy fails because of this line of code in ubios-cert.sh. Not sure if this is a hang over from a previous way acme.sh used to work?

# Re-write CERT_NAME if it is a wildcard cert. Replace '*' with '_'
ACME_CERT_NAME=$(echo "${CERT_NAME}" | sed -r 's/\*/_/g')

Changing it to the following resolves the issue:
ACME_CERT_NAME="${CERT_NAME}"

Tried to use Cloudflare to receive the certificate. Have been able to do this on a windows machine with winacme.exe.
Each initial run ends with an error:

[Mon Feb  6 16:06:41 CET 2023] invalid domain
[Mon Feb  6 16:06:41 CET 2023] Error add txt for domain:_acme-challenge.udm.adventist.be
[Mon Feb  6 16:06:41 CET 2023] Please check log file for more details: /mnt/data/ubios-cert/acme.sh/acme.sh.log

In the log you can see it querying for the root domain and getting nowhere:

[Mon Feb  6 16:06:39 CET 2023] h='adventist.be'
[Mon Feb  6 16:06:39 CET 2023] zones?name=adventist.be&account.id=xxxxAccountIDxxxx
[Mon Feb  6 16:06:39 CET 2023] GET
[Mon Feb  6 16:06:39 CET 2023] url='https://api.cloudflare.com/client/v4/zones?name=adventist.be&account.id=xxxxAccountIDxxxx'
[Mon Feb  6 16:06:39 CET 2023] timeout=
[Mon Feb  6 16:06:39 CET 2023] _CURL='curl --silent --dump-header /mnt/data/ubios-cert/acme.sh/http.header  -L  -g '
[Mon Feb  6 16:06:40 CET 2023] ret='0'

When entering https://api.cloudflare.com/client/v4/zones?name=adventist.be&account.id=xxxxAccountIDxxxx in a browser the following error from the api of cloudflare is returned:

{"success":false,"errors":[{"code":9106,"message":"Missing X-Auth-Email header"},{"code":9107,"message":"Missing X-Auth-Key header"}],"messages":[],"result":null}

So I guess there is some information not sent to cloudflare, or cloudflare has updated its api calls?

Is this "+" symbol supposed to be there (at end of the line):

Issue

When I use the ubios-cert.sh script to generate and deploy a cert for mydomain.com, I noticed that sometime after 10 - 30 minutes that all my DNS queries will point to the default network's gateway's IP address. This is resulting in my browser going to the unifi console login. This is happening for any wildcard *.mydomain.com as well.

I set the DNS settings to Auto for my Internet -> Primary (WAN1) network and all my internal networks as well.

What I found that resolved the issue for me

In the ubios-cert.sh file I commented out the lines that created the unifi-core-direct.crt and unifi-core-direct.key files. When the unifi-core service restarted I noticed that the unifi-core-direct.crt and unifi-core-direct.key were automatically created anyways.

I noticed that if I remove them and restart the unifi-core service, the unifi-core-direct.crt's subject is changed to <string of hex characters>.id.ui.direct. I inspected the cert by using openssl x509 -noout -text -in unifi-core-direct.crt

The lines that I commented out:

		cp -f ${ACMESH_ROOT}/${CERT_NAME}/fullchain.cer ${UNIFIOS_CERT_PATH}/unifi-core-direct.crt
		cp -f ${ACMESH_ROOT}/${CERT_NAME}/${CERT_NAME}.key ${UNIFIOS_CERT_PATH}/unifi-core-direct.key
		chmod 644 ${UNIFIOS_CERT_PATH}/unifi-core.crt ${UNIFIOS_CERT_PATH}/unifi-core-direct.crt
		chmod 644 ${UNIFIOS_CERT_PATH}/unifi-core.key ${UNIFIOS_CERT_PATH}/unifi-core-direct.key

Question

Is it okay if I make a PR to remove these lines? Or should I raise this issue up to the unifi community forums?

UDM Info

Model: UDM Pro
UniFi OS UDM Pro: v3.0.20
Network: 7.4.156

Do exactly what the title says.

It took a while to understand why the cron were not functionnal on Unifi-OS 3.x on my UDM-SE. It seems that now, the cron are required to specify under which user they will be executed.

Before and not working anymore:
0 3 * * * sh /data/ubios-cert/ubios-cert.sh renew
After and working fine on Unifi-OS 3.x:
0 3 * * * root /data/ubios-cert/ubios-cert.sh renew

Not sure why 'sh' should be used so I removed it. I need to test it on my UDM Pro which is on Unifi-OS 1.x.

          my internal CA is as follows:

Root CA
Intermediate CA
Router certificate

the router certificate is signed by my intermediate CA.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            83:a3:ae:9a:21:e4:00:4c:d2:89:5a:99:f9:41:fb:ad
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: O = PaulGG Intranet, CN = PaulGG Intranet Intermediate CA
        Validity
            Not Before: Dec 14 12:04:01 2023 GMT
            Not After : Dec 15 12:05:01 2023 GMT
        Subject: CN = router.paulgg.int
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:a2:dc:42:d7:35:b3:dd:5b:96:86:29:4c:64:e7:
                    32:48:1c:0a:bb:e6:5f:43:ad:63:de:19:12:3e:3f:
                    a5:52:f3:20:1e:30:23:c4:ac:56:aa:d8:b8:5d:ae:
                    d8:fe:6b:e8:ce:c5:b6:e6:c8:20:36:e0:98:35:3f:
                    b5:c3:d3:51:cc:91:ca:1d:38:a7:c8:9c:9e:7b:9a:
                    5e:41:e1:5b:38:7e:b8:7d:6e:a3:d7:51:11:b9:c7:
                    1c:be:f7:44:b2:a9:f5:63:1a:f3:43:64:ea:11:f1:
                    97:4b:6b:a6:e4:95:e1:05:98:45:4f:63:8b:ae:ac:
                    8d:aa:7d:9b:a5:d8:b8:1d:61:5e:c1:9b:3a:d8:91:
                    45:57:a0:d6:b7:1c:d4:88:4e:01:e5:c3:61:b4:6d:
                    68:1d:c8:2c:00:9a:e8:fb:0c:76:f1:f0:b8:d2:22:
                    3b:35:c8:9c:b9:80:db:7b:d9:ee:b3:af:b0:0d:fc:
                    70:b8:ef:0b:f6:4c:39:b5:c8:d0:9c:86:b3:71:a1:
                    a5:42:26:f7:3e:82:4c:23:a0:84:67:f6:0a:a9:34:
                    eb:ac:f2:f6:bc:a5:f5:6e:1a:34:e8:2a:a6:7e:42:
                    90:28:b9:db:34:1d:0d:b7:a1:1a:65:d3:61:55:ad:
                    ec:52:0a:fe:f5:11:41:1d:21:12:25:fc:02:e8:4d:
                    9d:cd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:58:1E:16:42:18:5A:CF:A5:DA:29:2E:37:50:AF:4E:5D:1B:CE:B9:93

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                98:41:E0:9B:1A:F8:23:F4:8F:6C:D7:53:37:A4:4E:D6:79:D3:A9:57
            X509v3 Subject Alternative Name:
                DNS:router.paulgg.int
            1.3.6.1.4.1.37476.9000.64.1:
                [email protected].+V5B126r4pfQJE_PkrMvSvc_gFds2wEs5EhzVSdSF-dQ
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:be:81:ea:60:62:19:71:3e:0b:54:48:43:79:
         56:5f:b5:59:23:dc:21:1b:94:16:07:a6:74:f6:5a:24:ff:af:
         43:02:20:25:29:02:8e:64:0f:01:b0:4e:b8:3d:47:8c:c5:b1:
         f1:80:46:86:fd:48:55:df:65:fb:af:fb:2e:24:eb:8f:a9

I just checked /etc/ssl/certs and looks like there's some stuff that has been deleted, including my root certificate from the keystore.

When I have some more time I'll play around with this...

Originally posted by @therealpaulgg in #61 (comment)

Does anyone know the difference between the
/mnt/data/udapi-config/raddb/certs/server.pem certificate which ENABLE_RADIUS='yes' updates and the
/mnt/data/udapi-config/raddb/certs/ca.pem certificate which appears when RADIUS users authenticate to a WPA Enterprise SSID?

I don't have good way to test the replacement of the ca.pem certificate and thought I'd ask before endeavoring to test. Google searches for /mnt/data/udapi-config/raddb/certs/ca.pem were not helpful.

I can confirm that the script does successfully copy the acme-generated certificate to the /mnt/data/udapi-config/raddb/certs/ directory, I just can't seem to find where it actually utilizes the certificate.

Documenting pre-replacement permissions for posterity here:

# ls -l /mnt/data/udapi-config/raddb/certs/
total 16
-rw-------    1 root     root          1834 Jan 21  2021 ca.key
-rw-r--r--    1 root     root          1562 Jan 21  2021 ca.pem
-rw-------    1 root     root          1675 Dec 19 15:09 server-key.pem
-rw-------    1 root     root          2013 Dec 19 15:09 server.pem

          @alxwolf sorry to necro this issue..but I am not so sure that 3.2.7 is so happy with custom certificates.

While I don't use this script specifically (I have a internal CA that I use to generate certificates for my intranet), I do at the very least replace /data/unifi-core/config/unifi-core.crt along with /data/unifi-core/config/unifi-core.key. Upon restarting unifi-core with systemctl restart unifi-core, the OS overwrites my custom certificates, effectively undoing my work.

My setup has been working for months and I never had to mess with keystore or the RADIUS config (raddb). I am trying to reach out to anyone who might know more. Only reason I noticed this was because my monitoring software detected it couldn't reach my router anymore...then did some digging and found this stuff out. Router must have updated at 3am causing this to break.

Originally posted by @therealpaulgg in #60 (comment)

    A good start but this should be re-opened as the scripts in `ubios-cert/ubios-cert.sh` and `ubios-cert/on_boot.d/99-ubios-cert.sh` also need to be updated to reflect the use of `/data` and not `/mnt/data` which is hardcoded in these scripts.

Originally posted by @mojo333 in #29 (comment)

While troubleshooting #2 I noticed that when I set ENABLE_RADIUS='yes' in my /mnt/data/ubios-cert/ubios-cert.env file, I get a pair of cp: can't stat errors between the production of the certificate and the stopping of unifi-os (redacted my domain below) when I'm deploying a wildcard cert.

[Sun Dec 19 03:41:34 UTC 2021] And the full chain certs is there: /acme.sh/*.domain.tld/fullchain.cer
No new certificate was found, exiting without restart
**cp: can't stat '/mnt/data/ubios-cert/acme.sh/_.domain.tld/_.domain.tld.cer': No such file or directory
cp: can't stat '/mnt/data/ubios-cert/acme.sh/_.domain.tld/_.domain.tld.key': No such file or directory**
unifi-os: Stopping unifi-os

I haven't had time to figure out whether this poses an actual problem, but I assume it does. I'm not sure if something in how line 25 transforms the CERT_NAME variable: ACME_CERT_NAME=${CERT_NAME/\*/_}

This issue does not seem to occur when I specify subdomains.

My UDM-PRO is running 1.10.4; the Network is running 6.5.53

Hello, I'm trying to run the radius_cert_update branch but I'm getting stuck.

I first attempted following the git command and just renaming that folder from ubios-cert-radius_cert_update to ubios-cert-main to just follow the guide line by line. However, when I got to the line: cd ${DATA_DIR}/ubios-cert , I got the warning: "-bash: cd: /ubios-cert: No such file or directory". Okay, no biggie. I typed cd /data and then cd ubios-cert. Then I tried running ./ubios-cert.sh initial and got the error: "./ubios-cert.sh: 42: /data/ubios-cert/ubios-cert.env: Syntax error: newline unexpected"

Not sure what I'm doing wrong here. I'm using Terminal on macOS to SSH in to a UDM Pro running v2.5.16.

Thoughts? Also, not entirely sure what I need to change to update the radius certificate properly since the instructions mention to use the other branch, but no other details.

Hi,

2022-05-01 was the last time my UDMPro was able to auto-renew its SSL certificate. I just found that it hasn't been updating my certificate automatically since.

It turns out that even though my /mnt/data/ubios-cert/ubios-cert.env file was configured for DEFAULT_CA="letsencrypt" when /mnt/data/ubios-cert/ubios-cert.sh renew ran, it tried to use ZeroSSL and errored out like this:

Please specify at least one validation method: '--webroot', '--standalone', '--apache', '--nginx' or '--dns' etc

Even if I run /mnt/data/ubios-cert/ubios-cert setdefaultca before running either the renew or forcerenew parameters, it still tries to use ZeroSSL and errors out like this:

Attempting certificate renewal
Removed old logfile
[Wed Aug 17 03:56:17 UTC 2022] Renew: 'domain.tld'
[Wed Aug 17 03:56:25 UTC 2022] Using CA: https://acme.zerossl.com/v2/DV90
[Wed Aug 17 03:56:25 UTC 2022] No EAB credentials found for ZeroSSL, let's get one
[Wed Aug 17 03:56:25 UTC 2022] acme.sh is using ZeroSSL as default CA now.
[Wed Aug 17 03:56:25 UTC 2022] Please update your account with an email address first.
[Wed Aug 17 03:56:25 UTC 2022] acme.sh --register-account -m [email protected]
[Wed Aug 17 03:56:25 UTC 2022] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
[Wed Aug 17 03:56:25 UTC 2022] Please check log file for more details: /acme.sh/acme.sh.log

I was able to re-initialize my cert and isolate the issue to the need to update the defaultCA by running

sh /mnt/data/ubios-cert/ubios-cert.sh setdefaultca
sh /mnt/data/ubios-cert/ubios-cert.sh initial

After this worked, I was able to force a renewal by adding --set-default-ca --server ${DEFAULT_CA} from the setdefaultca) section to the forcerenew) section (sorry, I don't know the right terminology), so line 135 became:

${PODMAN_CMD} --renew ${PODMAN_DOMAINS} --force --dns ${DNS_API_PROVIDER} --keylength 2048 ${PODMAN_LOG} --set-default-ca --server ${DEFAULT_CA} && deploy_cert

I was going to fork this and submit a pull request, but I wasn't sure if this is the most elegant way to fix this or whether there was a deeper root cause that needed to be addressed.

Issued the certificate perfectly fine, but installing doesn't work... it's missing the keytool binary? I wasn't able to find it anywhere on the machine?! did they remove java on it? I looked for openjk and apt is only showing release in an "oldstable" source... not sure if I'm supposed to install that!?

Dream Machine with
UDM v3.1.16
Network 7.5.176

./ubios-cert.sh: line 69: keytool: command not found
./ubios-cert.sh: line 72: keytool: command not found

UniFi OS UDM SE 3.0.18
[Mon Mar 27 13:10:06 CDT 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Mon Mar 27 13:10:07 CDT 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Mon Mar 27 13:10:07 CDT 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Mon Mar 27 13:10:07 CDT 2023] No doh
[Mon Mar 27 13:10:07 CDT 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Mon Mar 27 13:10:07 CDT 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60

I saw "Send a note if you succeeded with a different provider and I will list it here." on the Readme file and thought I'd chime in with how I was able to get the CloudFlare API to work.

Obtain your CloudFlare Token

1. Log into your CloudFlare account.
2. Click your avatar in the top right corner.
3. Click My Profile in the drop-down menu.
4. Click API Tokens in the left nav.
5. Click the Create Token button.
6. Navigate down to Create Custom Token and click the Get Started button.
7. Give your API token a descriptive name (it doesn't matter and you can change it later).
8. Under Permissions, set it to Zone - DNS - Edit
9. Under Zone Resources, set it to Include - Specific Zone - [the domain you want to use]
10. Configure TTL to your liking--can leave blank to make it indefinite.
11. Note the Token string. Guard it like a password.

Obtain your CloudFlare Account ID

1. Exit My Profile and navigate to the domain you want to use.
2. Note your Account ID in the right nav.

Edit your /mnt/data/ubios-cert/ubios-cert.env file

1. Duplicate this line (line 19 as of 2021-12-18) DNS_API_PROVIDER="dns_kas"
2. Comment out the original with an octothorp: # DNS_API_PROVIDER="dns_kas"
3. Replace kas with cf in the uncommented duplicate: DNS_API_PROVIDER="dns_cf"
4. Duplicate this line (line 33 as of 2021-12-18) DNS_API_ENV="-e KAS_Login=w0xxxxx -e KAS_Authdata=abcd...efgh -e KAS_Authtype=sha1"
5. Comment out the original with an octothorp
6. Populate the uncommented duplicate with your information: DNS_API_ENV="-e CF_Token=TokenBlahBlah -e CF_Account_ID=AccountIDBlahBlah”
7. Save and run (you might need to de-install and de-register and re-install for it to take effect--I've had some trial and error with this process)

I hope this helps!

Created a separate branch to work on this topic. Seems a bit more complicated than expected and equally "well-documented" by Ubiquiti as usual.

Linked with issue #12 and PR #13

Hi,
I noticed there is a new version of the acme.sh script (3.0.2) and was wondering whether/how this implementation might accommodate updates to the acme.sh script.

I have acme.sh deployed on another platform and I can see the script file there, but I could not find the acme.sh script via the find command (find / -name acme.sh) command or in the directory on the UDM.

# ls -la /mnt/data/ubios-cert/acme.sh/
total 28
drwx------    4 nobody   nogroup       4096 Jan 15 06:00 .
drwxrwxrwx    4 root     root          4096 Dec 19 15:44 ..
-rw-------    1 root     root           338 Jan 15 06:00 account.conf
-rw-r--r--    1 root     root          1246 Jan 15 06:00 acme.sh.log
drwxr-xr-x    3 root     root          4096 Dec 19 15:45 ca
-rw-r--r--    1 root     root           490 Jan  9 06:00 http.header
drwxr-xr-x    2 root     root          4096 Dec 26 06:00 subdomain.domain.tld

I noticed ubios-cert.sh uses podman to load the "neilpang/acme.sh" image, but I wasn't sure how it obtains the image. I'm new to all of this and was wondering if adding something like podman pull neilpang/acme.sh:latest somewhere at launch could ensure the latest version was automatically loaded.

This is on a UDM pro running UnifiOS version 3.1.16 and Network version 7.5.174. The core GUI cert is updating fine, and RADIUS cert is updating fine. When I go to https://(hostname of my udm):8443 I still get a cert error and it is still giving a cert that is self-signed by Ubiquiti. I'm wondering if the newest OS version and network is no longer allowing this to update.

The logic on what path to use probably need to be adjusted t look at the firmware version not hardware model. I just updated to 2.4.23 and had to tweak the scripts.

Sorry if it's obvious for some by I can't nail this deployment on my UDM SE. I see the /mnt/data changed to /data, this is fine. I see it needs docker, I tried installing it following instructions from https://github.com/unifi-utilities/unifios-utilities. Both from the README and some Issues I found. All the zip archives are expired so I don't know where I can get this.

It's not straight forward or maybe it's just me. If anyone can tell me if they succeed how they did deploy podman with a little bit of details. It doesn't exist on the UDM SE and all the procedure I see seem to talk about updating it.

Or maybe there is a simple way of not using podman for acme I don't know. I have read podman will not persist a firmware update so I would be tempted to run acmesh directly from a folder in /data... Does this make sense

Let me know!
Thanks.

Hello, I upgraded the firmware on my UDM-Pro OS Version 2.5.17 and Network 7.3.83 and updated the certificate with the newest version of this script.

For some reason I’m getting the certificate error when accessing the captive portal. Not currently at the site to get the error but will be back on Saturday. But wanted to make sure if other users captive portal works? Making sure to see if I did something wrong. The older version of this script worked fine. I put ‘yes’ in the ENABLE_CAPTIVE and kept the ‘yes’ in the FULLCHAIN. I did not get an error when issuing the cert and it shows when checking the domain that the cert has been applied.

Thank you

Hey great work on the script.

I'm however having an issue where some devices, mostly Samsungs and Apple devices do not trust the certificate on the guest portal.
SSL Checker indicates this warning "The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate. Learn more about this error. The fastest way to fix this problem is to contact your SSL provider." when I check the guest portal url.

Any help with this would be highly apricated.

Hi there,

Thank you for your work here.

I was able to use CloudFlare's DNS API with your ubios-cert.env file, however, setting line 9 ENABLE_CAPTIVE='no'
causes the following error:

java.lang.IllegalStateException: no issuer certificate found
	at com.ubnt.service.system.Z.?00000(Unknown Source)
	at java.util.Optional.orElseThrow(Optional.java:290)
	at com.ubnt.service.system.Z.super(Unknown Source)
	at com.ubnt.service.system.Z.super(Unknown Source)
	at com.ubnt.service.system.Z.?00000(Unknown Source)
	at com.ubnt.ace.Launcher.main(Unknown Source)
Error: non zero exit code: 1: OCI runtime error

After I saw this error, I followed your De-installation and de-registration steps.

I then followed the Installation steps, but tried different settings in the /mnt/data/ubios-cert/ubios-cert.env file; de-installing and de-registering after each test:

• Set a wildcard instead of specific hosts for CERT_HOSTS; ENABLE_CAPTIVE='no'; ENABLE_RADIUS='no' (Succeeded without errors)
• Set a wildcard instead of specific hosts for CERT_HOSTS; ENABLE_CAPTIVE='no'; ENABLE_RADIUS='yes' (Succeeded with a pair of cp: can't stat errors)
• Set a wildcard instead of specific hosts for CERT_HOSTS; ENABLE_CAPTIVE='yes'; ENABLE_RADIUS='yes' (Reproduced issue)
• Set a wildcard instead of specific hosts for CERT_HOSTS; ENABLE_CAPTIVE='yes'; ENABLE_RADIUS='no' (Reproduced issue)
• Set specific hosts for CERT_HOSTS; ENABLE_CAPTIVE='no'; ENABLE_RADIUS='yes' (Succeeded with a pair of cp: can't stat errors)
• Set specific hosts for CERT_HOSTS; ENABLE_CAPTIVE='yes'; ENABLE_RADIUS='no' (Reproduced issue)

I tried to Google the errors, but couldn't find anything.

I inspected the directories and they all had the expected certificate files.

My UDM-PRO is running 1.10.4.

Hello, just installed this couple days ago and was wondering if there’s an option to add email notification when the certificate is renewed?

Hi

Thanks for this - just installed it on my UDMP running UniFi OS 3.2.7. Not fully tested but looking go so far.

I have spotted one small issue - README.MD has an error in 'FIRST RUN' section:

cp /data/udapi-server/raddb/certs/server.pem ./raddb-server.pem
cp /data/udapi-server/raddb/certs/server-key.pem ./raddb-server-key.pem

I believe /data/udapi-server should be /data/udapi-config ?

The code (ubios-cert.env) does refer to /data/udapi-config though.

# Path to RADIUS server certificate
UBIOS_RADIUS_CERT_PATH='/data/udapi-config/raddb/certs'

Thanks

Pete

1. deploy.sh fails for me as I get the following when executing:

root@UDMP:/data/letsencrypt/ubios-cert-main# ./deploy.sh
Unsupported model: UniFi Dream Machine Pro

Adding an echo just before the case statement shows that ${MODEL} evaluates to just "UniFi" and hence why the case statement fails... something to do with spaces in the variable. Not sure how to fix this as I'm no bsh expert.

2. ubios-cert.sh also needs updated code to handle UDMPro 2.4.23 as was done for deploy.sh - see excerpt below:

# When running in UDM SE / UDR, the applications are not running in containers
case "$(ubnt-device-info model || true)" in "UniFi Dream Machine SE"|"UniFi Dream Router")
	# But here, the same command will be executed but inside unifi-os container
	IS_UNIFI_2='true'
	;;
esac

Hello world,

In the course of troubleshooting #2 I discovered that if you want to specify a non-default CA,
you have to run sh /mnt/data/ubios-cert/ubios-cert.sh initial
before you can run sh /mnt/data/ubios-cert/ubios-cert.sh setdefaultca

Otherwise, it will error out thusly:
Error: error checking path "/mnt/data/ubios-cert/acme.sh": stat /mnt/data/ubios-cert/acme.sh: no such file or directory

I think it errors out like this because the setdefaultca switch doesn't install acme.sh, but requires acme.sh to be present so it can set a different value for DEFAULT_CA.

In the course of un/re-installing this script several times, I found that I had to

• first run sh /mnt/data/ubios-cert/ubios-cert.sh initial
• let it fail
• then run sh /mnt/data/ubios-cert/ubios-cert.sh setdefaultca
• then re-run sh /mnt/data/ubios-cert/ubios-cert.sh initial

to get it to utilize the DEFAULT_CA value from my /mnt/data/ubios-cert/ubios-cert.env file.

Not a big deal, but I thought I'd report it here. I'm not very good at scripting, but I wonder if the ubios-cert.sh script could check to see if acme.sh is installed first before proceeding. Seems like it would be good for the initial, setdefaultca, and cleanup switches to know about ahead of time.

Hi,
I succeeded to configure OVH as a DNS API Provider

OVH

export DNS_API_PROVIDER="dns_ovh"
export OVH_AK="ggdffettdgggdggd"
export OVH_AS="mlksdjfgmsjgkshgerhgz"
export OVH_CK="dlfkjhdmfgjozrhfgjozarhgoreaig"

Does anyone know if this will work on the UNVR? It would be cool to be able to set an SSL cert on this device as well. Seems like it runs as its own instance in the unifi ecosystem.