[GH-ISSUE #1637] Wrong SSL certificate used in information blob #1024

New issue

Closed

opened 2026-03-02 02:20:41 +03:00 by kerem · 1 comment

kerem commented

2026-03-02 02:20:41 +03:00

Owner

Originally created by @elia-blue on GitHub (Sep 21, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1637

Server Info (please complete the following information):

OS: Debian 11
Browser: Firefox ESR
RMM Version (as shown in top left of web UI): 0.16.4

Installation Method:

Standard
Docker

Agent Info (please complete the following information): not applicable

Describe the bug
The SSL certificate warning in the UI uses the wrong certificate for getting its information.

To Reproduce
Steps to reproduce the behavior:

Use an SSL cert e.g. rmm.example.com-0001 for NGINX
Specify the use of this certificate in local_settings.py

Expected behavior
The SSL certificate warning shows the correct expiration date.

Additional context
The problem lies (I think) in the get_certs() or days_until_cert_expires() in api/tacticalrmm/tacticalrmm/helpers.py. I don't know why, but this function seems to ignore the settings / suffix from local_settings.py. I fixed the problem on my side by renamimg the cert to rmm.example.com, now everything works as expected, but this behaviour should still be looked into I think.

Also, thank you guys for your great software :)

Originally created by @elia-blue on GitHub (Sep 21, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1637 **Server Info (please complete the following information):** - OS: Debian 11 - Browser: Firefox ESR - RMM Version (as shown in top left of web UI): 0.16.4 **Installation Method:** - [X] Standard - [ ] Docker **Agent Info (please complete the following information):** not applicable **Describe the bug** The SSL certificate warning in the UI uses the wrong certificate for getting its information. **To Reproduce** Steps to reproduce the behavior: 1. Use an SSL cert e.g. `rmm.example.com-0001` for NGINX 2. Specify the use of this certificate in `local_settings.py` **Expected behavior** The SSL certificate warning shows the correct expiration date. **Additional context** The problem lies (I think) in the `get_certs()` or `days_until_cert_expires()` in `api/tacticalrmm/tacticalrmm/helpers.py`. I don't know why, but this function seems to ignore the settings / suffix from `local_settings.py`. I fixed the problem on my side by renamimg the cert to `rmm.example.com`, now everything works as expected, but this behaviour should still be looked into I think. Also, thank you guys for your great software :)

kerem closed this issue

2026-03-02 02:20:41 +03:00

kerem commented

2026-03-02 02:20:42 +03:00

Author

Owner

@wh1te909 commented on GitHub (Sep 21, 2023):

trmm needs either a wildcard cert, or a cert for api.example.com with 2 SANs for rmm.example.com and mesh.example.com. If you are using the letsencrypt wildcard created by the install script then there is no additional settings changes needed.

If you are using your own wildcard, or the SAN method, as stated in the docs here, then you must let TRMM know the location of your fullchain and privkey otherwise trmm has no idea that you are doing custom certs (like you are now). So follow the docs linked above and then it will show the correct dates.

@wh1te909 commented on GitHub (Sep 21, 2023): trmm needs either a wildcard cert, or a cert for api.example.com with 2 SANs for rmm.example.com and mesh.example.com. If you are using the letsencrypt wildcard created by the install script then there is no additional settings changes needed. If you are using your own wildcard, or the SAN method, as stated in the docs [here](https://docs.tacticalrmm.com/functions/settings_override/#using-your-own-wildcard-ssl-cert), then you must let TRMM know the location of your fullchain and privkey otherwise trmm has no idea that you are doing custom certs (like you are now). So follow the docs linked above and then it will show the correct dates.

kerem referenced this issue

2026-03-14 04:38:23 +03:00

[GH-ISSUE #1024] Debian Installation Issues #2573