{"id":1926,"date":"2025-11-16T17:24:04","date_gmt":"2025-11-16T14:24:04","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/acme-challenges-deep-dive-the-friendly-guide-to-http%e2%80%9101-dns%e2%80%9101-and-tls%e2%80%91alpn%e2%80%9101\/"},"modified":"2025-11-16T17:24:04","modified_gmt":"2025-11-16T14:24:04","slug":"acme-challenges-deep-dive-the-friendly-guide-to-http%e2%80%9101-dns%e2%80%9101-and-tls%e2%80%91alpn%e2%80%9101","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/acme-challenges-deep-dive-the-friendly-guide-to-http%e2%80%9101-dns%e2%80%9101-and-tls%e2%80%91alpn%e2%80%9101\/","title":{"rendered":"ACME Challenges Deep Dive: The Friendly Guide to HTTP\u201101, DNS\u201101, and TLS\u2011ALPN\u201101"},"content":{"rendered":"

So there I was, sipping a late coffee while a production deploy ticked away, when a message popped up: \u201cWildcard cert needed in 10 minutes. Any chance?\u201d You know that feeling\u2014you can almost hear the clock ticking. I smiled because, years ago, that would\u2019ve sent me into panic mode. Now? I\u2019ve learned when to reach for HTTP\u201101, when DNS\u201101 saves the day, and when TLS\u2011ALPN\u201101 is the quiet hero nobody talks about. And yes, we hit the deadline, and the world kept spinning.<\/p>\n

Ever had that moment when you\u2019re staring at an SSL error, a countdown in your head, and you\u2019re not sure which ACME challenge to use? You\u2019re not alone. The good news is you don\u2019t have to guess. Each challenge type fits a different shape of problem\u2014you just need to know the shapes. In this post, we\u2019ll walk through the three main ACME validation methods, how they feel in real life, and the kinds of situations where each one shines. No drama, no jargon for the sake of jargon\u2014just the real talk I wish someone had given me earlier.<\/p>\n

The ACME Story in Plain English<\/h2>\n

Here\u2019s the simple picture: certificate authorities need proof that you control a domain before they hand you a shiny TLS certificate. The ACME protocol is the handshake that automates this trust dance. You ask for a cert, they challenge you to prove control, you respond the right way, and boom\u2014certificate issued. There are three main ways to prove it: by serving a special file over HTTP, by placing a special TXT record in DNS, or by presenting a special certificate over a specific TLS protocol on port 443. Those are HTTP\u201101, DNS\u201101, and TLS\u2011ALPN\u201101.<\/p>\n

Think of it like delivery options. HTTP\u201101 knocks on your front door at port 80 and asks for a note you taped to the inside of the glass. DNS\u201101 checks your mailbox at the registrar and reads a note you tucked in there. TLS\u2011ALPN\u201101 walks straight to the garage on port 443 and asks to see your special parking pass. Same goal, different paths.<\/p>\n

In my experience, the biggest challenge isn\u2019t the theory\u2014it\u2019s the messy, real-world stuff. Load balancers. CDNs. Kubernetes Ingress. Multi-tenant SaaS. Split-horizon DNS. WAFs that mean well but get in the way. And, of course, the tiny window between \u201ccertificate expiring soon\u201d and \u201csomeone DMing you that the app looks untrusted now.\u201d The trick is knowing which method steps around those obstacles instead of tripping over them.<\/p>\n

One more thing: there\u2019s no \u201cbest\u201d challenge in the abstract. There\u2019s the one that\u2019s simplest for your setup today, and the one that scales for your setup tomorrow. Sometimes they\u2019re the same. Sometimes you switch\u2014and that\u2019s fine. I do it all the time when a system grows up and needs something sturdier.<\/p>\n

HTTP\u201101: The Straight Shot (When the Web Server Is the Star)<\/h2>\n

When someone says, \u201cI just need a cert for my site,\u201d nine times out of ten, HTTP\u201101 is what they actually want\u2014even if they haven\u2019t heard the name. It\u2019s the simplest to picture: the CA visits http:\/\/yourdomain\/.well-known\/acme-challenge\/some-token, and your server returns a tiny file with precisely the right content. If they can fetch it at port 80, you win.<\/p>\n

There\u2019s a reason HTTP\u201101 feels so natural. You\u2019re proving control via the same pathway people already use to reach your site. It\u2019s easy to automate with a webroot or a small on-server helper. On a single server with vanilla Nginx or Apache, you can have it humming in minutes. Certbot, lego, or acme.sh can drop the token in a special folder; your web server is configured to serve that folder precisely as-is; certificate issued; renewals on autopilot.<\/p>\n

But here\u2019s the thing: the world is rarely \u201csingle server and nothing else.\u201d The first bump in the road is port 80 itself. HTTP\u201101 requires port 80 to be reachable from the public internet. If you\u2019ve disabled port 80 entirely for security or aesthetics, HTTP\u201101 won\u2019t work. Redirecting 80 to 443 is fine\u2014ACME will happily follow a redirect\u2014but the initial knock still has to happen on 80. If a firewall slams the door, the CA can\u2019t even start the conversation.<\/p>\n

The second bump is anything that changes or filters the request before it hits your server. A WAF, CDN, or load balancer can get too clever and rewrite, compress, or block the challenge path. Reverse proxies sometimes handle that well with pass-through exceptions; sometimes not. I\u2019ve had a CDN cache a 404 and stubbornly serve it for the challenge path until I purged it. Fun times. In those cases, a simple rule that bypasses caching and security for the challenge endpoint usually fixes it.<\/p>\n

Then there\u2019s the multi-server dance. If you\u2019re running multiple web servers behind a load balancer, the challenge file has to be served consistently from whichever server gets the request. That means shared storage for the challenge folder, sticky sessions, or a small helper that intercepts the challenge and responds directly. I\u2019ve done all three. The cleanest pattern is often having your reverse proxy or Ingress controller answer the challenge centrally, so you don\u2019t have to sync files across nodes.<\/p>\n

One random gotcha: some redirect rules accidentally swallow the challenge path. A global \u201credirect everything to HTTPS and www\u201d can cause the challenge file to disappear or be rewritten. Whenever I set up HTTP\u201101, I double-check two things: that \/.well-known\/acme-challenge is served as-is with no auth, and that the request doesn\u2019t get rerouted to an app or a different hostname.<\/p>\n

Where HTTP\u201101 shines is the common case: a typical website or API served from a publicly reachable web server, no wildcard domains needed. It\u2019s easy, it\u2019s familiar, and it\u2019s fast. If you\u2019re using a CDN or WAF, it still works\u2014you just have to make sure the challenge path is excluded from the fancy stuff. When I\u2019m onboarding a simple site, HTTP\u201101 is usually the first thing I try, because production likes boring and predictable.<\/p>\n

When does HTTP\u201101 not feel right? If you need wildcard certificates, you can stop reading this section: HTTP\u201101 can\u2019t do it. If your site is always behind a CDN that terminates TLS and refuses to pass challenge traffic to the origin, it can get awkward. And if port 80 is blocked or intentionally disabled, you\u2019ll be happier with one of the other methods.<\/p>\n

DNS\u201101: The Scaler\u2019s Favorite (Wildcard, SaaS, and Off-Path Control)<\/h2>\n

DNS\u201101 is the proof that lives in your domain\u2019s DNA. Instead of serving a file, you publish a TXT record named _acme-challenge.yourdomain with a specific value. The CA does a DNS lookup for that record, verifies it matches what they expect, and issues the certificate. You don\u2019t need any web server at all\u2014and that\u2019s exactly why it\u2019s powerful.<\/p>\n

If you\u2019ve ever needed a wildcard certificate\u2014like *.example.com\u2014DNS\u201101 is your only option among the main challenges. I still remember my first wildcard rollout for a client who had apps popping up like mushrooms after rain. One certificate, one renewal system, and we were done. No chasing every subdomain. That was the day DNS\u201101 earned a permanent spot in my toolkit.<\/p>\n

Beyond wildcard, DNS\u201101 is gold when your app sits behind layers: CDNs that terminate TLS, zero-trust networks, private origins, or environments where port 80 simply isn\u2019t reachable. Since validation happens at the DNS layer, it doesn\u2019t care about your web routing. I\u2019ve used it to issue certs for services that weren\u2019t even listening on the public internet\u2014think internal dashboards published through tunnels or access gateways. The CA only needs to read your TXT record, and you\u2019re good.<\/p>\n

Now, the trade-off: automation depends on your DNS provider\u2019s API. If your provider exposes a solid API, DNS\u201101 is as smooth as HTTP\u201101. If not, you end up clicking around in a dashboard every 60\u201390 days, which is exactly the kind of thing we forget until alerts start blinking. I\u2019ve been there at midnight, adding TXT records by hand with a mug of tea and a sense of impending doom. These days, I try to avoid any setup that requires manual DNS.<\/p>\n

Propagation is another subtlety. Your ACME client will create the _acme-challenge TXT record and immediately ask the CA to check it. Most good clients pause long enough for propagation, and many providers publish changes within seconds. But some providers have a lag or a form of eventual consistency. In those cases, a slightly longer wait before verification is your friend. Keeping the TTL on challenge records short also helps keep things snappy.<\/p>\n

In multi-tenant SaaS, DNS\u201101 scales beautifully. If you offer \u201cbring your own domain\u201d and want auto-SSL for every customer domain, HTTP\u201101 quickly becomes a maze of routing and per-domain exceptions. With DNS\u201101, you hook into DNS provider APIs\u2014or use a delegated validation zone\u2014and you can issue certs without touching the tenant\u2019s web traffic path. I wrote about this model in detail in Bring Your Own Domain, Get Auto\u2011SSL: How DNS\u201101 ACME Scales Multi\u2011Tenant SaaS Without Drama<\/a>, and it still might be the single biggest quality-of-life upgrade for SaaS teams trying to avoid certificate chaos.<\/p>\n

DNS architecture matters, too. If you\u2019re using multiple DNS providers for redundancy or migration safety, automate thoughtfully. I run multi-provider DNS with octoDNS specifically so I can flip providers without breaking automation, and I covered the playbook in How I Run Multi\u2011Provider DNS with octoDNS (and Sleep Through Migrations)<\/a>. The reality: your ACME client needs to know which provider actually answers authoritative queries and how to write TXT records there. Keep that source of truth crystal clear.<\/p>\n

Last thought here: CAA records. They decide which CAs are allowed to issue for your domain. If you lock that down (which you should), remember to update CAA when you change CAs or add a backup. I dug into that in The CAA Records Deep Dive<\/a>. DNS\u201101 and CAA are old friends\u2014get them to play nicely, and your automation becomes both flexible and safe.<\/p>\n

TLS\u2011ALPN\u201101: The Quiet Specialist (When 443 Is Your Only Door)<\/h2>\n

TLS\u2011ALPN\u201101 is the one most folks hear about last, but it\u2019s a lifesaver when the other doors are shut. Here\u2019s the gist: the CA connects to your server over TLS on port 443 and uses ALPN (Application-Layer Protocol Negotiation) to ask for a special protocol called acme-tls\/1. Your server responds with a special, temporary certificate that proves you control the domain. No HTTP needed. No DNS changes needed. Just 443.<\/p>\n

Why does this matter? Some environments never expose port 80. Others don\u2019t want to touch DNS or can\u2019t automate it easily. In tightly controlled networks, or where you\u2019ve locked everything down to HTTPS only, TLS\u2011ALPN\u201101 slides right through. I\u2019ve used it in setups where a reverse proxy or Ingress could terminate TLS with a tiny helper that knows how to speak ALPN correctly, answer only for the challenge, and then disappear. It feels almost sneaky\u2014in a good way.<\/p>\n

But here\u2019s the catch: if something terminates TLS in front of your server\u2014like a CDN or a managed WAF that doesn\u2019t pass through ALPN or SNI the way you need\u2014TLS\u2011ALPN\u201101 can\u2019t work. The CA needs to see that special acme-tls\/1 exchange all the way to the origin. With a fully proxied CDN, that\u2019s usually a no. In those cases, DNS\u201101 is your friend, because it sidesteps the traffic path entirely.<\/p>\n

The other subtlety is that TLS\u2011ALPN\u201101, like HTTP\u201101, doesn\u2019t do wildcard certificates. If you\u2019re aiming for *.example.com, head back to DNS\u201101. That\u2019s not a bug; it\u2019s just how the spec works. When I have a cluster or app that forbids port 80 and doesn\u2019t need wildcards, I reach for TLS\u2011ALPN\u201101 because it\u2019s elegant and self-contained. It also plays nicely with immutable infrastructure because you don\u2019t need to coordinate file writes to webroots.<\/p>\n

If you want to peek under the hood, the ACME base protocol is documented in RFC 8555<\/a>, and the TLS\u2011ALPN\u201101 extension lives in RFC 8737<\/a>. And if you prefer a friendlier overview, the Let\u2019s Encrypt challenge types guide<\/a> maps the lay of the land nicely.<\/p>\n

Real-World Scenarios: Which One Fits?<\/h2>\n

Let me walk you through a few moments where picking the right challenge made all the difference. These aren\u2019t contrived; they\u2019re the kind of situations that show up on a Tuesday afternoon when you\u2019re juggling three other priorities.<\/p>\n

Scenario one: a single WordPress site on a VPS<\/a>. No CDN in front, Nginx serving with a standard config, and port 80 is open. I\u2019d go with HTTP\u201101 every time. It\u2019s the fewest moving parts, easy to debug, and renewals just work. If I\u2019m already using something like acme.sh or certbot, I\u2019ll point it to a webroot or use a small standalone server that spins up only for validation. Keep it boring, keep it reliable.<\/p>\n

Scenario two: a site behind a CDN that proxies everything and refuses to pass the challenge cleanly to the origin. I tried poking holes for \/.well-known\/acme-challenge, but the CDN kept \u201chelping\u201d by caching and inspecting the request. Rather than fight it, I switched to DNS\u201101. Now the certificate lifecycle is independent of the traffic path, which is exactly what you want when the network layer is opinionated.<\/p>\n

Scenario three: wildcard needed by yesterday. The team wanted *.example.com for subdomains that spun up on demand. This is where DNS\u201101 is the only sane choice. I wired the DNS provider API into the ACME client, set the TTLs low, and made sure propagation windows were long enough before the CA checked. On renewal day, no one had to be awake at 3 a.m. to paste a TXT record.<\/p>\n

Scenario four: a private origin behind a tunnel and strict HTTPS-only policy. There was no incoming 80, and I didn\u2019t want to open it even briefly. TLS\u2011ALPN\u201101 was perfect here. The Ingress layer spoke ALPN, served the temporary validation cert, and nobody had to fiddle with DNS or console logins. If you\u2019re experimenting with zero-trust networking and private publishing, you might enjoy how gentle that flow feels. If that topic interests you, I\u2019ve also written about a related pattern in The Calm, Zero\u2011Trust Way to Publish Apps Without Opening a Single Port<\/a>, which pairs nicely with thoughtful ACME automation.<\/p>\n

Scenario five: multi-tenant SaaS with bring-your-own-domain onboarding. The team wanted to issue certificates as soon as a customer pointed their domain. Doing that with HTTP\u201101 meant fancy routing and per-tenant exceptions\u2014a headache that grows geometrically with every new domain. With DNS\u201101, we built a clean, automated flow with delegated validation and job queues. The payoff was huge: onboarding felt instant, and certificate renewals became background noise. If you want the deeper playbook, the SaaS article I linked earlier breaks down the moving parts.<\/p>\n

Scenario six: clusters and CAs. In Kubernetes, I\u2019ve used cert-manager with both HTTP\u201101 and DNS\u201101. If your Ingress controller has a built-in solver for HTTP\u201101, it\u2019s lovely for conventional apps. But once you start serving many hostnames or wildcards, DNS\u201101 simplifies the picture. I\u2019ve also paired this with a backup CA strategy so rate limits don\u2019t surprise me at scale, as I describe in Redundant ACME Automation That Just Works: acme.sh Fallback from Let\u2019s Encrypt to ZeroSSL<\/a>. Nothing like sleeping through renewals because your automation already knows Plan B.<\/p>\n

Automation That Doesn\u2019t Wake You Up at 3 a.m.<\/h2>\n

Let\u2019s talk process, because the best challenge choice still fails if the automation is brittle. My north star is simple: if a renewal fails once, I don\u2019t just fix the symptom\u2014I make sure that failure can\u2019t happen again without me hearing about it early and loudly. Here\u2019s how that plays out with each challenge, woven into real workflows rather than theory.<\/p>\n

With HTTP\u201101, I prefer a single, predictable path for challenge files that bypasses application logic. In Nginx, that means a dedicated location for .well-known\/acme-challenge that returns files directly from disk or a tiny memory-backed handler. No auth, no redirects, no headers that mangle content. In multi-node layouts, I\u2019ll let the load balancer or Ingress intercept and answer the challenge itself, so I\u2019m not syncing files across boxes. It\u2019s one less moving part.<\/p>\n

With DNS\u201101, the heart of reliability is the DNS API integration. I keep credentials scoped tightly\u2014just enough privileges to create and delete TXT records in the validation zone\u2014and I store those secrets outside the app repo. If the provider supports it, I use a sub-zone like _acme-challenge.example.com delegated to a separate authoritative server or token management service. That way the validation plumbing stays separate from the \u201creal\u201d DNS, and teams don\u2019t trip over each other. If you\u2019re on multiple providers, make the source of truth explicit and keep the client pointed at the one actually answering queries. If you want a blueprint for multi-provider sanity, the octoDNS article I linked earlier shows exactly how I avoid surprises.<\/p>\n

With TLS\u2011ALPN\u201101, I test in the exact network path that production will use, because tiny differences in TLS termination can break validation. If there\u2019s a CDN in front, TLS\u2011ALPN\u201101 probably won\u2019t work; I default to DNS\u201101 instead. If the path is direct to the origin through a load balancer or Ingress you control, it\u2019s usually smooth sailing. Keep an eye on SNI handling and make sure your ALPN helper only answers for the domains under validation, then gets out of the way.<\/p>\n

No matter the challenge, I run a staging environment with a staging CA first. It\u2019s astonishing how many \u201cworks on my machine\u201d stories vanish when you point at a staging CA that behaves like the real one but doesn\u2019t burn your rate limits. Once the flow is solid, I flip to production. I also keep a backup CA ready to go. If you\u2019ve ever tripped rate limits or hit a temporary outage, having a fallback already integrated is priceless. I outlined a concrete approach in my acme.sh fallback guide<\/a>, and it\u2019s saved me more than once.<\/p>\n

Alerting is the last part of the puzzle. I don\u2019t want to hear about expirations a day before they happen\u2014I want to know the first time a renewal fails, even if it still has weeks left. That means parsing logs, watching exit codes, or wiring a health check that verifies the live certificate on critical endpoints. For teams that value sleep, this is the difference between \u201cOh, that\u2019s interesting\u201d and \u201cWhy are we on a call at 2 a.m.?\u201d<\/p>\n

Now a quick word about policy and posture. If you lock down CAA records (please do), remember to include every CA you actually use, including the fallback. If you rotate providers, update CAA first. I\u2019ve seen teams spend an hour debugging a perfectly good automation because CAA quietly said \u201cnope.\u201d Also watch your DNS TTLs for _acme-challenge; short TTLs make retries faster and keep you from waiting on propagation when something goes sideways.<\/p>\n

One practical pro-tip: keep your ACME account key safe and backed up. If you rebuild automation from scratch and accidentally create a new account without realizing it, you might hit \u201ctoo many new orders\u201d limits and wonder why a flow that used to be fine is suddenly flaky. The account is part of your identity with the CA\u2014treat it like a credential.<\/p>\n

A Quick Mental Checklist (No Tables, Just Gut Checks)<\/h2>\n

When I\u2019m choosing between HTTP\u201101, DNS\u201101, and TLS\u2011ALPN\u201101 on a new project, I ask a few gentle questions. Is port 80 open and straightforward? If yes, HTTP\u201101 is probably the least effort. Do I need wildcards or want the validation to be totally independent of traffic routing? DNS\u201101 starts to look really attractive. Is port 80 closed but 443 is clean all the way to an origin I control, and no wildcard needed? TLS\u2011ALPN\u201101 might be the sweet spot.<\/p>\n

If the app sits behind a forceful CDN or WAF that I don\u2019t fully control, DNS\u201101 usually wins by sidestepping the path. If we\u2019re talking bring-your-own-domain SaaS, DNS\u201101 scales better than anything else. And if I\u2019m in a place where I can\u2019t\u2014or don\u2019t want to\u2014touch DNS, but I do control how TLS terminates, TLS\u2011ALPN\u201101 keeps things elegant.<\/p>\n

That\u2019s it. No scoring chart, no complicated matrix. Just a few sensible questions that match the messy reality of your setup. Your goal isn\u2019t to pick the \u201cfanciest\u201d method\u2014it\u2019s to pick the one that won\u2019t wake you up later.<\/p>\n

The Human Bits: Stories From the Trenches<\/h2>\n

One of my clients had a global launch with region-specific subdomains on a tight deadline. They planned to use HTTP\u201101 across multiple regions, but a last-minute CDN rule started caching 404s for the challenge path. Rather than fight the clock, we switched to DNS\u201101, automated the TXT records, and the rollout finished while the CDN folks were still reading the change tickets. Sometimes the best fix is the one that avoids the argument entirely.<\/p>\n

Another time, a security-conscious team insisted on no open port 80 anywhere. They were right to be cautious\u2014compliance demanded it. We implemented TLS\u2011ALPN\u201101 at the edge, validated cleanly on 443, and kept the auditors happy. They didn\u2019t need wildcards, and we controlled the TLS termination layer, so it felt like slipping the key into exactly the right lock.<\/p>\n

And of course, the late-night wildcard story. I can\u2019t tell you how nice it is to create *.example.com once with DNS\u201101 and be done with it. The team spun up new subdomains like they were adding routes in the app. Certificates never crossed their minds, which is how it should be. The success criteria for ACME, in my book, is that nobody on the feature team ever has to think about certificates again.<\/p>\n

Wrap\u2011Up: Pick the Calm Path, and Make It Boring<\/h2>\n

If you remember one thing from this deep dive, let it be this: choose the ACME challenge that keeps your architecture boring. HTTP\u201101 is the straight shot when port 80 is open and the traffic path is simple. DNS\u201101 is the powerhouse when you want wildcards, clean SaaS onboarding, or you\u2019re behind layers that you don\u2019t fully control. TLS\u2011ALPN\u201101 is the elegant specialist for HTTPS-only environments where you control the TLS handshake but don\u2019t want to touch DNS. None is \u201cbetter\u201d in isolation; each is right for its moment.<\/p>\n

From there, make your automation resilient. Test with a staging CA, wire in alerts for the first failure, keep a backup CA ready, and make sure your CAA and DNS are in sync with your plans. If you\u2019re curious about resilient DNS or multi-CA strategies, I shared my playbooks in my octoDNS guide<\/a> and the redundancy article<\/a>, and they pair beautifully with DNS\u201101 at scale.<\/p>\n

Alright\u2014take a breath. Certificates don\u2019t have to be dramatic. Pick the path that matches your world today, set it up so failures are loud and early, and then let it fade into the background while you build the things your users actually see. Hope this was helpful! See you in the next post, and may your renewals be blissfully boring.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"

So there I was, sipping a late coffee while a production deploy ticked away, when a message popped up: \u201cWildcard cert needed in 10 minutes. Any chance?\u201d You know that feeling\u2014you can almost hear the clock ticking. I smiled because, years ago, that would\u2019ve sent me into panic mode. Now? I\u2019ve learned when to reach […]<\/p>\n","protected":false},"author":1,"featured_media":1927,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-1926","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1926","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=1926"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1926\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/1927"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=1926"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=1926"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=1926"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}