I have managed to setup my internal AD domain at home.mydomain.com which works fine. No issues there. I have then created some certificates for internal services by setting up the DNS hostnames for them externally and using my internal DNS server to resolve them to local IP addresses. This also works fine. So, I can access my-service.home.mydomain.com.
Now, the issue is my DHCP is setup to provide a dns suffix of home. So, I can type https://my-service/ in the address bar and browse to the site. My question is, is there a way I can make the certificate valid for that address?
Only if you issue a cert for that name from your trusted AD CA.
And your client in joined to that domain [or at least has explicitly added your AD root CA cert to their trusted store].
But there is no global CA than can issue such a cert [which is required when using HTTPS].
You could use http://my-service/ locally and then redirect that to https://my-service.home.mydomain.com/
But if you want to use a real trusted globally signed CA cert, then that (long) FQDN must be from an Internet resolvable domain name - not from a domain that only exists on your LAN.
You could also use a self-signed certificate that you manually accept in your browser, and in theory your server could even have separate virtual hosts for these and serve the self-signed one only when it is accessed as https://my-service/ but not when it's accessed under the FQDN.
Or you could use a browser extension that automatically rewrites the https://my-service/ URLs to the FQDN version inside your browser.
EFF's HTTPS Everywhere extension (which works in browsers that are compatible with Chrome extensions) can do this with a custom rewrite rule, although I'm sure that if that's all you want to do, there must be a different extension out there that makes that specific task easier.
