Web Deploy can quietly drop the SSL binding on the next deploy.
Application Initialization preloads HTTP and caches it before the cert is restored.
ASP.NET agencies running IIS on Windows Server or Kestrel behind nginx and IIS reverse proxies deal with Web Deploy losing the SSL binding after a deploy (Application Initialization preloads HTTP and caches), Windows Server CRL fetch timeouts on outbound HTTPS calls when the firewall blocks the CRL distribution point (looks like a third-party API outage but is internal firewall config), and Kestrel behind reverse proxy generating HTTP URLs in URL.Action() when ForwardedHeaders middleware isn't reading X-Forwarded-Proto. Merlonix monitors SSL and DNS so login redirects don't break with mixed-content warnings before you know the binding was lost.
No credit card for the trial. Cancel any time.
- Check cadence (Agency)
- 5 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where ASP.NET agencies get caught out
Three failure modes specific to ASP.NET deployments on IIS or Kestrel behind reverse proxies, with Windows Server CRL revocation checks and cross-pool URL generation.
ASP.NET agencies deal with IIS Web Deploy losing the SSL binding after a deploy (Application Initialization preloads HTTP and caches HTTP-flavored absolute URLs into the warm pool), Windows Server CRL fetch timeouts on outbound HTTPS calls when default-deny firewall rules block the CRL distribution point (looks like a third-party API outage but is internal firewall config), and Kestrel behind reverse proxy generating HTTP URLs in Url.Action() when ForwardedHeaders middleware can't read X-Forwarded-Proto after an nginx hardening change strips the header.
IIS deploys via Web Deploy or msdeploy can drop the SSL binding when the deploy package overwrites the site config without preserving the existing cert binding. After deploy, the site falls back to HTTP-only binding or a self-signed cert. IIS Application Initialization preloads pages over HTTP and caches the warm pool with HTTP-only state — by the time a real user request hits over HTTPS, the cached pool returns HTTP redirect targets in the response payload
An ASP.NET agency deploys a client e-commerce app to IIS on Windows Server via Visual Studio Web Deploy. The deploy succeeds; IIS reports the site as running. The deploy package included a default applicationHost.config snippet that does not preserve the SSL binding the agency had configured manually months earlier. The site's 443 binding is now bound to a self-signed Personal store cert instead of the WebHosting store cert with the proper chain. Application Initialization warmup hits the home page over HTTP (because the redirect rule maps HTTP to HTTPS but warmup runs before the redirect rule is evaluated)
An ASP.NET agency operates a client e-commerce app on IIS / Windows Server 2022. The agency deploys updates via Visual Studio Web Deploy with the publish profile set to overwrite. The publish profile includes the standard applicationHost.config additions for url-rewrite redirect rules and Application Initialization warmup paths — but does not include the explicit SSL binding declaration (it was added manually via IIS Manager months earlier and has been carried implicitly across upgrades by the runtime). The next deploy of the WebHostBuilder-generated package overwrites the site config; IIS resets the 443 binding to a default Personal store cert that doesn't match the production CN. Application Initialization preloads /Home and /Catalog pages over HTTP before the URL-rewrite redirect-to-HTTPS rule is evaluated; the warmed pool now caches HTTP-flavored absolute URLs in cross-page links. User requests over HTTPS hit the warm pool and receive responses with HTTP absolute URLs in <a> tags. Browsers issue mixed-content warnings; Chrome's strict-transport-security policy degrades the experience further. The agency engineer assumes a CSS regression and spends two hours in DevTools before checking the IIS binding panel and seeing the cert mismatch.
ASP.NET HttpClient (and the underlying .NET SslStream) checks the cert's revocation status by default. The CRL distribution point URL is embedded in the cert; Windows Server makes an outbound HTTPS call to fetch the CRL during the chain validation step. When the agency's firewall blocks outbound 443 except to whitelisted domains (default-deny outbound rules common in regulated industries), the CRL fetch times out and Windows defaults to rejecting the cert with RemoteCertificateChainErrors. The third-party API call fails — looks like an API outage but is internal firewall config
An ASP.NET agency runs a client backend on Windows Server inside a corporate network with default-deny outbound rules. The app calls a third-party payments API — Stripe, Adyen, or similar. Windows Server can't reach the cert's CRL distribution point because the firewall blocks outbound 443 to anything not on the whitelist. The HttpClient call fails with RemoteCertificateChainErrors. Stripe's status page shows green; engineering thinks Stripe is having an issue but the actual root cause is the corporate firewall blocking CRL fetches
An ASP.NET agency operates a client B2B product on Windows Server inside a corporate network with default-deny outbound firewall rules — only specifically whitelisted destinations are allowed. The app calls Stripe's API to charge subscriptions. The Stripe API cert's X.509 chain references a CRL distribution point at https://crl3.digicert.com or similar. When ASP.NET's HttpClient initiates the HTTPS connection, the underlying SslStream chain validation step makes an outbound HTTPS call to the CRL URL to verify the cert hasn't been revoked. The corporate firewall blocks the outbound connection because crl3.digicert.com isn't on the whitelist. The CRL fetch times out (typically 15-30 seconds for the default Windows timeout). Windows defaults to "rejecting cert with offline revocation status" — the SslStream returns RemoteCertificateChainErrors with chain status RevocationStatusUnknown. The HttpClient throws HttpRequestException with no clear root-cause hint. The agency engineer checks Stripe's status page (green), tests the Stripe API from their dev laptop (works), and spends most of a day debugging Stripe SDK version mismatches before someone suggests checking outbound firewall rules. The fix is whitelisting the CRL distribution point hosts (or disabling revocation checking, which is a security regression). Without monitoring the outbound CRL fetch path, this failure pattern can repeat every time a third-party API rotates its cert chain.
ASP.NET Core Kestrel behind a reverse proxy (IIS, nginx, or AWS ALB) needs the ForwardedHeaders middleware configured to read X-Forwarded-Proto so Url.Action() and ASP.NET's automatic-HTTPS-redirect middleware know whether the original request came over HTTPS. When the upstream stops sending X-Forwarded-Proto (after a config change) or the middleware isn't configured, ASP.NET treats requests as HTTP, generates HTTP absolute URLs in cross-page redirects, and login redirects break with mixed-content warnings
An ASP.NET agency runs a client SaaS on Kestrel behind nginx as a reverse proxy. nginx terminates SSL and forwards plain HTTP to Kestrel. The agency configures ASP.NET's ForwardedHeaders middleware in Startup.Configure to trust X-Forwarded-Proto from nginx. After a security review, nginx is updated to strip X-Forwarded-Proto by default for inbound requests (a strict-mode security policy). Kestrel now sees plain HTTP requests with no proto header. ASP.NET's Url.Action() starts generating http:// absolute URLs. Login redirects break with mixed-content warnings
An ASP.NET agency operates a client SaaS deployed to Linux servers running ASP.NET Core 8 under Kestrel behind nginx as a reverse proxy. nginx terminates SSL with the production cert; Kestrel listens on 127.0.0.1:5000 and serves HTTP. ASP.NET's Startup.Configure includes app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedFor }) so the app correctly identifies HTTPS-originated requests. The setup works for two years. A security review at the client requires nginx to be hardened — the new nginx config sets `proxy_set_header X-Forwarded-Proto ""` to strip any inbound X-Forwarded-Proto header that might be spoofed by a malicious upstream (the security team's threat model assumed nginx might be behind a CDN that could inject headers). The setting accidentally also strips outbound X-Forwarded-Proto going to Kestrel. Kestrel now sees every request as HTTP. ASP.NET's automatic-HTTPS-redirect middleware doesn't trigger (it sees HTTPS already because of the absent X-Forwarded-Proto), Url.Action() generates http:// absolute URLs in form action attributes, login form POST goes to http://app.client.com/account/login. Browsers issue mixed-content blocked warnings; the form silently fails to submit. The agency engineer assumes a CSRF token regression and spends an afternoon debugging Razor view rendering before someone notices the form action shows http:// in DevTools.
How it works
SSL and DNS monitoring for ASP.NET agencies across IIS Web Deploy SSL binding lifecycle, Windows Server CRL revocation checks, and Kestrel reverse-proxy X-Forwarded-Proto header propagation.
Merlonix monitors SSL expiry and full chain validation (including revocation status reachability) across every ASP.NET-attached subdomain — apex, app.*, api.*, plus per-pool IIS hosts and per-tenant Kestrel hosts — and catches IIS Web Deploy-induced SSL binding loss, Windows Server CRL fetch timeouts blocked by default-deny corporate firewalls (looks like a third-party API outage but is internal firewall config), and Kestrel behind reverse proxy generating HTTP URLs in Url.Action() after an nginx hardening change strips X-Forwarded-Proto — before login redirects break with mixed-content warnings.
01
Add ASP.NET application domains — apex, www.*, app.*, api.*, plus per-pool IIS subdomains and per-tenant Kestrel hosts — with DNS TXT record verification
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (IIS or Kestrel-fronted), api.* (typically Web API on Kestrel), plus per-pool IIS subdomains and per-tenant Kestrel hosts — are added without additional verification. Monitoring every ASP.NET-attached subdomain catches IIS deploy-induced SSL binding loss before Application Initialization caches HTTP-flavored absolute URLs into the warm pool, and catches Kestrel-behind-reverse-proxy mixed-content patterns before login redirects break. Under two minutes per client.
02
A record and CNAME monitoring across IIS-fronted Windows Server hosts, Kestrel-behind-nginx Linux deployments, and Azure App Service / AWS Elastic Beanstalk managed ASP.NET hosting
Three independent DNS resolvers check every A record and CNAME delegation on every monitoring interval. When a client moves an ASP.NET workload from on-prem Windows Server to Azure App Service mid-cert-cycle, the new resolution path is validated across all monitored subdomains. When the agency adds a CDN (Cloudflare, Fastly) in front of an existing IIS deployment and the corporate firewall now blocks outbound CRL fetches on a different path, the DNS change is logged alongside the cert chain validation results so the firewall-induced revocation-check failure has a clear root cause.
03
SSL monitoring 30 days before expiry across IIS site bindings, Kestrel cert handling, ASP.NET HttpClient outbound chain validation including CRL revocation status checks, and full chain validation that catches missing intermediates
Full SSL chain validation on every ASP.NET-attached subdomain — apex, app.*, api.*, plus per-pool and per-tenant subdomains. The chain check explicitly validates revocation status reachability so CRL fetch failures (the kind that break ASP.NET HttpClient calls behind default-deny corporate firewalls) are caught before a third-party API integration starts failing with RemoteCertificateChainErrors that looks like an API outage. An expiry alert fires 30 days before the certificate expires — enough lead time to identify whether the failure is a Web Deploy that dropped the SSL binding, a CRL distribution point newly blocked by an updated firewall whitelist, or a Kestrel reverse-proxy header config change that broke X-Forwarded-Proto.
04
Vendor status for Microsoft Azure, AWS (for ASP.NET Core hosted on EC2 or Elastic Beanstalk), Stripe / Adyen and other typical ASP.NET-stack third-party API providers, plus DigiCert / Sectigo and other typical Windows Server cert authorities
Merlonix monitors Microsoft Azure, AWS, Stripe, Adyen, DigiCert, Sectigo, and other typical ASP.NET-stack vendors' status pages alongside client SSL and DNS. When a Stripe API regional incident causes payment failures across multiple ASP.NET client deployments simultaneously, you see the vendor event — not a cluster of individual SSL alerts that each require separate investigation to determine whether the root cause is a Stripe regional outage, a Windows Server CRL fetch timeout from a firewall whitelist change, or an IIS deploy that dropped the SSL binding two days ago.
What the numbers mean for ASP.NET agencies
Monitoring built for ASP.NET agencies where one client product means an IIS-hosted marketing site, a Kestrel-behind-nginx Web API at api.*, and an outbound HttpClient pipeline that calls Stripe and Adyen — each with independent SSL surfaces and independent failure modes spanning IIS bindings, Windows CRL revocation checks, and reverse-proxy header propagation.
ASP.NET agencies managing IIS Web Deploy SSL binding lifecycle across multi-client Windows Server hosts, Windows Server CRL revocation checks against third-party API certs across default-deny corporate firewall environments, and Kestrel behind reverse proxy X-Forwarded-Proto header propagation across multi-server deployments need monitoring that explicitly validates revocation reachability — because a CRL fetch timeout looks like a third-party API outage but is internal firewall config, and Web Deploy can quietly drop an SSL binding that took years to set up.
< 10 min
Time from DNS change to alert — catches CDN additions in front of existing IIS hosts that change the outbound CRL fetch path, ASP.NET workload migrations from on-prem Windows Server to Azure App Service mid-cert-cycle, and Kestrel-behind-reverse-proxy host changes during multi-server deployments
30 days
SSL expiry warning lead time — enough time to identify a Web Deploy that dropped the SSL binding, a CRL distribution point newly blocked by an updated corporate firewall whitelist, or a Kestrel reverse-proxy header config change that broke X-Forwarded-Proto, and correct it before the IIS warm pool caches HTTP-flavored absolute URLs or login redirects break with mixed-content warnings
11 vendors
Upstream services monitored — Microsoft Azure, AWS, Stripe, Adyen, DigiCert, Sectigo, and other typical ASP.NET-stack third-party API and cert authority providers included to distinguish provider outages from ASP.NET-specific SSL configuration failures
200 assets
Maximum monitored domains on the Agency plan — covers ASP.NET app.*, api.*, per-pool IIS hosts, and per-tenant Kestrel hosts across a full ASP.NET client portfolio
Pricing
Flat monthly fee. Every IIS site binding and Kestrel host included.
No per-binding charges. No per-pool fees. Pick the tier that fits your ASP.NET client and per-pool count and monitor every IIS site binding, Kestrel host, and outbound HttpClient cert chain without billing surprises.
Starter
For individual ASP.NET developers managing a small client portfolio with single-server IIS or Kestrel deployments.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For ASP.NET agencies managing multi-client deployments across IIS Web Deploy and Kestrel-behind-nginx with separate apex, app.*, and api.* subdomains.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full ASP.NET client roster including per-pool IIS subdomains, per-tenant Kestrel hosts, and outbound HttpClient pipelines to Stripe and Adyen.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when an IIS Web Deploy is about to drop the SSL binding or a CRL fetch is about to fail behind a default-deny firewall.
Add your first ASP.NET client domain in under two minutes. IIS site bindings, Kestrel hosts, and outbound HttpClient cert chains across every server and every client are monitored from the same dashboard. 14-day trial, no card required.