starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 15:05:57 +03:00

[GH-ISSUE #1895] Tactical RMM Instructions say 3 domains are needed, but asks for 4. #3121

New issue

Closed

opened 2026-03-14 06:36:24 +03:00 by kerem · 7 comments

kerem commented

2026-03-14 06:36:24 +03:00

Owner

Originally created by @W1BTR on GitHub (Jun 17, 2024).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1895

The docs say the following:

The RMM uses 3 different sites. The Vue frontend e.g. rmm.example.com which is where you'll be accessing your RMM from the browser, the REST backend e.g. api.example.com and MeshCentral e.g. mesh.example.com
rmm. api. and mesh. are what we recommend, but you can use whatever you want if they're already in use.

Which makes me think I would want:
api.mydomain.com
mesh.mydomain.com
and rmm.mydomain.com

However, when setting up, Tactical RMM also asks for my ROOT domain, which would be mydomain.com

However, mydomain.com is already in use for something else. I dont understand what this fourth domain is for. Can I just set it to rmm.mydomain.com as well?

I can do api.rmm.mydomain.com etc if need be.

Originally created by @W1BTR on GitHub (Jun 17, 2024). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1895 The docs say the following: ``` The RMM uses 3 different sites. The Vue frontend e.g. rmm.example.com which is where you'll be accessing your RMM from the browser, the REST backend e.g. api.example.com and MeshCentral e.g. mesh.example.com rmm. api. and mesh. are what we recommend, but you can use whatever you want if they're already in use. ``` Which makes me think I would want: api.mydomain.com mesh.mydomain.com and rmm.mydomain.com However, when setting up, Tactical RMM also asks for my ROOT domain, which would be mydomain.com ![image](https://github.com/amidaware/tacticalrmm/assets/164893442/00e8c7d1-80d9-4fde-bd96-f2f7d4970cf7) However, mydomain.com is already in use for something else. I dont understand what this fourth domain is for. Can I just set it to rmm.mydomain.com as well? I can do api.rmm.mydomain.com etc if need be.

kerem closed this issue

2026-03-14 06:36:29 +03:00

kerem commented

2026-03-14 06:36:35 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 17, 2024):

no, it's just used in the certbot command to get the wildcard cert. has nothing to do with it being already used.

@wh1te909 commented on GitHub (Jun 17, 2024): no, it's just used in the certbot command to get the wildcard cert. has nothing to do with it being already used.

kerem commented

2026-03-14 06:36:40 +03:00

Author

Owner

@W1BTR commented on GitHub (Jun 17, 2024):

Okay, I dont want to sacrifice my entire domain so the wildcard cert will always fail. Why doesnt it get individual certs? Obviously as a workaround I can just have it behind another rmm subdomain, just seems silly.

@W1BTR commented on GitHub (Jun 17, 2024): Okay, I dont want to sacrifice my entire domain so the wildcard cert will always fail. Why doesnt it get individual certs? Obviously as a workaround I can just have it behind another rmm subdomain, just seems silly.

kerem commented

2026-03-14 06:36:45 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 17, 2024):

you can have as many certs as you want for your root domain, no sacrifice needed. nothing will break.

@wh1te909 commented on GitHub (Jun 17, 2024): you can have as many certs as you want for your root domain, no sacrifice needed. nothing will break.

kerem commented

2026-03-14 06:36:50 +03:00

Author

Owner

@W1BTR commented on GitHub (Jun 17, 2024):

All I can tell you is that it fails because it points to another IP address so it cant confirm I own it, where the other three point to this server.

@W1BTR commented on GitHub (Jun 17, 2024): All I can tell you is that it fails because it points to another IP address so it cant confirm I own it, where the other three point to this server.

kerem commented

2026-03-14 06:36:56 +03:00

Author

Owner

@dinger1986 commented on GitHub (Jun 17, 2024):

Yes you can cause it's got nothing to do with the IP address, you are adding a new TXT record for lets encrypt to get the wildcard

@dinger1986 commented on GitHub (Jun 17, 2024): Yes you can cause it's got nothing to do with the IP address, you are adding a new TXT record for lets encrypt to get the wildcard

kerem commented

2026-03-14 06:37:01 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 17, 2024):

the install script uses the DNS TXT record method to get the wildcard cert. it doesn't matter which IP your domain is pointed to. This is the reason we use TXT record so that you don't have to worry about IP addresses.

If you want you can just get a cert for api.example.com with 2 SANs for mesh.example.com and rmm.example.com and then call the install script with the --use-own-cert flag: https://docs.tacticalrmm.com/functions/settings_override/#using-your-own-wildcard-ssl-cert

@wh1te909 commented on GitHub (Jun 17, 2024): the install script uses the DNS TXT record method to get the wildcard cert. it doesn't matter which IP your domain is pointed to. This is the reason we use TXT record so that you don't have to worry about IP addresses. If you want you can just get a cert for `api.example.com` with 2 SANs for `mesh.example.com` and `rmm.example.com` and then call the install script with the `--use-own-cert` flag: https://docs.tacticalrmm.com/functions/settings_override/#using-your-own-wildcard-ssl-cert

kerem commented

2026-03-14 06:37:06 +03:00

Author

Owner

@W1BTR commented on GitHub (Jun 17, 2024):

Okay, I see what's going on. I've never seen / heard of certbot using txt challenges or anything other than the standard apache check, so I just glossed over it. My experience goes back a good number of years but appears more narrow than I'd thought. Apologies!

@W1BTR commented on GitHub (Jun 17, 2024): Okay, I see what's going on. I've never seen / heard of certbot using txt challenges or anything other than the standard apache check, so I just glossed over it. My experience goes back a good number of years but appears more narrow than I'd thought. Apologies!