Name your internal services after some valid DNS domain that you own. Options include
- use split DNS, where hostnames like "hr.example.com" resolve on your internal network but not externally
- use split DNS for a subdomain, so everything under "corp.example.com" points at your internal network and you use https://hr.corp.example.com (which might be easier to manage - you just reserve "corp.example.com" on your public DNS)
- buy a completely separate domain name like examplecorp or something
- go full beyondcorp and make https://login.corp.google.com available on the public internet, and rely on SSL + strong authentication (like two-factor) instead of people being on the internal network (as a bonus, this approach to IT makes things more straightforward if, hypothetically, there was a global pandemic forcing people to not be in the office for over a year, idk, that might not be a realistic business risk)
Now that your services are running on a DNS name you control, you can get real, valid SSL certificates for them. Assuming you didn't go with that last option, you can
- use Let's Encrypt DNS challenges, by temporarily adding TXT records mapping to your internal names
- use Let's Encrypt HTTPS challenges, by temporarily (or permanently) running a web server in external DNS that corresponds to your internal names
- pay for a wildcard certificate from a vendor, which costs under $100/year
The one risk here is that names of all real SSL certificates are logged publicly (for Certificate Transparency, to help track mis-issuance). So if you happen to enjoy running web servers named things like secret-plan-to-acquire-foobarcorp-on-july-30.corp.example.com, then you want to go with the wildcard option. If the names you have are things like "hr" or "wiki", you'll be fine with the Let's Encrypt option.
This approach requires no installing of certificates on end-user machines and no asking users to click through any dialogs and no risk of people on the internal network spoofing websites and doing a man-in-the-middle attack (which is only ever so slightly harder than using Wireshark).
- use split DNS, where hostnames like "hr.example.com" resolve on your internal network but not externally
- use split DNS for a subdomain, so everything under "corp.example.com" points at your internal network and you use https://hr.corp.example.com (which might be easier to manage - you just reserve "corp.example.com" on your public DNS)
- buy a completely separate domain name like examplecorp or something
- go full beyondcorp and make https://login.corp.google.com available on the public internet, and rely on SSL + strong authentication (like two-factor) instead of people being on the internal network (as a bonus, this approach to IT makes things more straightforward if, hypothetically, there was a global pandemic forcing people to not be in the office for over a year, idk, that might not be a realistic business risk)
Now that your services are running on a DNS name you control, you can get real, valid SSL certificates for them. Assuming you didn't go with that last option, you can
- use Let's Encrypt DNS challenges, by temporarily adding TXT records mapping to your internal names
- use Let's Encrypt HTTPS challenges, by temporarily (or permanently) running a web server in external DNS that corresponds to your internal names
- pay for a wildcard certificate from a vendor, which costs under $100/year
The one risk here is that names of all real SSL certificates are logged publicly (for Certificate Transparency, to help track mis-issuance). So if you happen to enjoy running web servers named things like secret-plan-to-acquire-foobarcorp-on-july-30.corp.example.com, then you want to go with the wildcard option. If the names you have are things like "hr" or "wiki", you'll be fine with the Let's Encrypt option.
This approach requires no installing of certificates on end-user machines and no asking users to click through any dialogs and no risk of people on the internal network spoofing websites and doing a man-in-the-middle attack (which is only ever so slightly harder than using Wireshark).