I'm part of a Microsoft-centric organization that operates both on-premises (using a local domain controller) and on the cloud (with Azure and Microsoft 365 for services like Teams, Exchange, and SharePoint). Currently, we use Caddy as a reverse proxy for various internal resources, which are served over HTTPS using self-signed certificates. The reason we opted for HTTPS is that many of these applications utilize OAuth with our cloud credentials, and Azure mandates HTTPS redirect URIs when registering applications.
Users can log in with their email accounts, and they are briefly redirected to Microsoft's OAuth flow. While this setup works, browsers show warnings about untrusted domains, prompting users to "accept risk to continue."
We also operate another Caddy instance for public-facing resources where the certificates are automatically managed using HTTP challenges. However, our DNS provider doesn't offer APIs for automatic challenge handling, unlike Cloudflare.
Here's our current setup:
- Our domain controller serves as the DNS server, with the default domain being `org.local`.
- DNS records route `docs.org.local` to the internal Caddy's on-premises IP.
- Caddy uses host headers to reverse proxy the connections appropriately.
What we're looking to achieve:
- Eliminate the untrusted certificate warnings for users.
- Allow other internal applications to securely access these services' APIs over HTTPS without encountering certificate validation errors. This is crucial for us.
I've been exploring options to issue a certificate from the domain controller and have Caddy utilize it, but I've gotten lost in the plethora of guides available, and I'm not even sure if that's the right course of action. Also, our cloud DNS is managed through Aruba Cloud, which complicates migrating to other DNS services. Any advice on how to obtain trusted certificates for our internal domains while maintaining Azure OAuth integration would be really appreciated!
5 Answers
Using Let's Encrypt in combination with an automated ACME client, like Certbot, is a really great move. It’s free, allows commercial use, and is trusted by all major certificate stores, including Microsoft. Alternatively, you could opt for paid services like Global Sign, though that can get quite expensive depending on your needs.
Creating your own Certificate Authority (CA) may be a viable option too. You can then distribute your CA certificate to users so they trust it without the warnings. This requires some policy management, but it keeps things under your control.
You don’t actually need an API from your DNS provider! Instead, you can utilize the new DNS-PERSIST-01 method for Let's Encrypt challenges. It can save you a lot of hassle!
It seems like you’re dealing with split-horizon DNS. I faced a similar issue, though I wasn't using OAuth. My workaround was to join my Linux hosts to Active Directory and deploy Windows Server Certificates using Ansible. Everything that comes from outside is routed through Nginx with Let's Encrypt certificates.
One effective solution is to purchase a wildcard certificate for your domain. This way, you only have to manage it centrally with Caddy, which simplifies the process. However, I’d recommend switching to a registrar that supports ACME challenges, as the shortening of certificate validity periods means you'll need to automate renewals soon. It's better to get started on that now!
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures