If your internal domain name matches an external domain name (e.g.
sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of
example.com assuming whoever owns
email@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.
If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like
sales.corp.example.local), then your only option is to use an internal CA.
If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).
Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.
As an aside:
The customer installs the software and it is good to go
That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:
- Customer may not have internet access from the host so you can't contact an external authority
- Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them
- Customer may require auditing of all certificates being issued for internal hostnames
In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.