{"id":1893,"date":"2025-11-15T21:02:04","date_gmt":"2025-11-15T18:02:04","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/the-caa-records-deep-dive-how-i-make-lets-encrypt-zerossl-issue-issuewild-iodef-and-a-multi%e2%80%91ca-strategy-play-nicely\/"},"modified":"2025-11-15T21:02:04","modified_gmt":"2025-11-15T18:02:04","slug":"the-caa-records-deep-dive-how-i-make-lets-encrypt-zerossl-issue-issuewild-iodef-and-a-multi%e2%80%91ca-strategy-play-nicely","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/the-caa-records-deep-dive-how-i-make-lets-encrypt-zerossl-issue-issuewild-iodef-and-a-multi%e2%80%91ca-strategy-play-nicely\/","title":{"rendered":"The CAA Records Deep Dive: How I Make Let\u2019s Encrypt, ZeroSSL, issue\/issuewild, iodef, and a Multi\u2011CA Strategy Play Nicely"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#The_moment_CAA_clicked_for_me\"><span class=\"toc_number toc_depth_1\">1<\/span> The moment CAA clicked for me<\/a><\/li><li><a href=\"#What_CAA_really_is_and_why_youll_grow_to_love_it\"><span class=\"toc_number toc_depth_1\">2<\/span> What CAA really is (and why you\u2019ll grow to love it)<\/a><\/li><li><a href=\"#The_anatomy_of_a_CAA_record_issue_issuewild_iodef_and_friends\"><span class=\"toc_number toc_depth_1\">3<\/span> The anatomy of a CAA record: issue, issuewild, iodef (and friends)<\/a><\/li><li><a href=\"#Lets_Encrypt_and_ZeroSSL_getting_authorization_right\"><span class=\"toc_number toc_depth_1\">4<\/span> Let\u2019s Encrypt and ZeroSSL: getting authorization right<\/a><\/li><li><a href=\"#Getting_the_wildcard_story_straight_issue_vs_issuewild\"><span class=\"toc_number toc_depth_1\">5<\/span> Getting the wildcard story straight: issue vs issuewild<\/a><\/li><li><a href=\"#iodef_the_unsung_hero_that_keeps_you_in_the_loop\"><span class=\"toc_number toc_depth_1\">6<\/span> iodef: the unsung hero that keeps you in the loop<\/a><\/li><li><a href=\"#A_calm_multiCA_strategy_that_just_works\"><span class=\"toc_number toc_depth_1\">7<\/span> A calm multi\u2011CA strategy that just works<\/a><\/li><li><a href=\"#Implementation_patterns_and_the_little_traps\"><span class=\"toc_number toc_depth_1\">8<\/span> Implementation patterns and the little traps<\/a><ul><li><a href=\"#Start_at_the_apex_then_secure_the_edges\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Start at the apex, then secure the edges<\/a><\/li><li><a href=\"#Be_explicit_about_wildcards\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Be explicit about wildcards<\/a><\/li><li><a href=\"#Use_account-level_constraints_where_it_helps\"><span class=\"toc_number toc_depth_2\">8.3<\/span> Use account-level constraints where it helps<\/a><\/li><li><a href=\"#Remember_the_CNAME_and_parent_walk\"><span class=\"toc_number toc_depth_2\">8.4<\/span> Remember the CNAME and parent walk<\/a><\/li><li><a href=\"#Propagation_TTLs_and_negative_answers\"><span class=\"toc_number toc_depth_2\">8.5<\/span> Propagation, TTLs, and negative answers<\/a><\/li><li><a href=\"#Testing_without_drama\"><span class=\"toc_number toc_depth_2\">8.6<\/span> Testing without drama<\/a><\/li><\/ul><\/li><li><a href=\"#A_quick_word_on_DNSSEC_and_CAA_trust\"><span class=\"toc_number toc_depth_1\">9<\/span> A quick word on DNSSEC and CAA trust<\/a><\/li><li><a href=\"#Wrapping_it_all_up_CAA_as_your_quiet_policy_engine\"><span class=\"toc_number toc_depth_1\">10<\/span> Wrapping it all up: CAA as your quiet policy engine<\/a><\/li><\/ul><\/div>\n<h2 id=\"section-1\"><span id=\"The_moment_CAA_clicked_for_me\">The moment CAA clicked for me<\/span><\/h2>\n<p>So there I was, late on a Thursday, sipping lukewarm coffee and staring at a DNS zone that absolutely refused to issue a wildcard certificate. The setup looked perfect. ACME automation was humming, DNS was clean, the validation was passing, and yet the CA kept replying with a polite \u201csorry, not authorized.\u201d I remember laughing out loud in that slightly unhinged way only sysadmins and DevOps folks will recognize. It wasn\u2019t the servers or the ACME client. It was <strong>CAA<\/strong>\u2014quiet, unobtrusive, and completely in charge of who gets to mint certs for your domain. The domain had a CAA record that allowed non-wildcard issuance, but not wildcard. Subtle. Brutal. Educational.<\/p>\n<p>If you\u2019ve ever had that \u201cwhy won\u2019t my certificate issue?\u201d moment, this is for you. We\u2019ll unpack CAA in a friendly, real-world way. We\u2019ll look at how Let\u2019s Encrypt and ZeroSSL read CAA, what <strong>issue<\/strong> and <strong>issuewild<\/strong> actually do, how <strong>iodef<\/strong> helps you get human-readable alerts, and the strategy I use to run a <strong>multi\u2011CA setup<\/strong> without drama. I\u2019ll share the patterns I lean on, the gotchas that still bite now and then, and the little habits that keep teams out of late-night firefights.<\/p>\n<h2 id=\"section-2\"><span id=\"What_CAA_really_is_and_why_youll_grow_to_love_it\">What CAA really is (and why you\u2019ll grow to love it)<\/span><\/h2>\n<p>CAA is like the guest list at a cozy dinner party. Only the names on that list get in. In DNS terms, a CAA record says which Certificate Authorities (CAs) are allowed to issue certificates for your domain. If there\u2019s no CAA record, any trusted CA can issue. If there is one, the rules kick in. The real win is control. You can bless Let\u2019s Encrypt for non-wildcard, bless ZeroSSL for wildcard, and route violation notices to your inbox with <strong>iodef<\/strong>. You can even tell a CA exactly which account is allowed to request a cert for your domain\u2014handy when you\u2019ve got multiple teams or vendors touching things.<\/p>\n<p>Here\u2019s the thing: CAA isn\u2019t flashy. You won\u2019t see a dashboard dancing with charts. But it\u2019s quietly mighty. It prevents accidental or unauthorized issuance, reduces surprise cert sprawl, and when you\u2019re doing ACME at scale, it becomes your guardrail. I\u2019ve seen organizations go from mystery certs appearing out of nowhere to a world where every certificate has a reason, a paper trail, and a predictable CA.<\/p>\n<h2 id=\"section-3\"><span id=\"The_anatomy_of_a_CAA_record_issue_issuewild_iodef_and_friends\">The anatomy of a CAA record: issue, issuewild, iodef (and friends)<\/span><\/h2>\n<p>Let\u2019s break the core tags down in plain English first, then we\u2019ll look at examples you can drop into a zone file.<\/p>\n<p><strong>issue<\/strong>: Authorizes certificate issuance for normal (non-wildcard) hostnames. If you say <em>issue &#8220;letsencrypt.org&#8221;<\/em>, you\u2019re telling the world that normal certificates for your domain can be issued by Let\u2019s Encrypt.<\/p>\n<p><strong>issuewild<\/strong>: Same idea, but specifically for wildcard certificates like <em>*.example.com<\/em>. This is where that Thursday-night debugging session went sideways for me. A domain can happily allow <em>issue<\/em> for Let\u2019s Encrypt, but if you forget <em>issuewild<\/em>, your wildcard orders will fail, even if everything else looks perfect.<\/p>\n<p><strong>iodef<\/strong>: This is your \u201cping me if something weird happens\u201d tag. You can provide an email or an HTTPS endpoint. If a CA finds something off\u2014or wants to send you a policy violation notice\u2014they use this contact. It\u2019s especially useful for big teams or multi-tenant systems where you want early heads-up.<\/p>\n<p>There are also optional parameters like <strong>accounturi<\/strong> that some CAs (notably Let\u2019s Encrypt) support. That\u2019s a way to say, \u201cEven if you\u2019re authorized, restrict issuance to this specific ACME account.\u201d It\u2019s an extra glove over the handshakes, and it helps when multiple automation stacks operate under the same domain.<\/p>\n<p>Here are realistic examples you can adapt. These go in your zone file or DNS control panel. Your syntax will differ a bit depending on the provider, but the shape is the same.<\/p>\n<pre class=\"language-python line-numbers\"><code class=\"language-python\">; Allow Let\u2019s Encrypt for normal certs\nexample.com.  CAA 0 issue &quot;letsencrypt.org&quot;\n\n; Allow ZeroSSL for normal certs as well\nexample.com.  CAA 0 issue &quot;zerossl.com&quot;\n\n; Explicitly allow wildcard issuance by Let\u2019s Encrypt and ZeroSSL\nexample.com.  CAA 0 issuewild &quot;letsencrypt.org&quot;\nexample.com.  CAA 0 issuewild &quot;zerossl.com&quot;\n\n; Deny issuance by everyone else (empty value)\n; Note: This forbids issuers at this label unless explicitly allowed elsewhere the CA is required to consider\n; (see discussion below about CNAME targets and parents)\nexample.com.  CAA 0 issue &quot;;&quot;\nexample.com.  CAA 0 issuewild &quot;;&quot;\n\n; Get notifications over email and HTTPS (CAs may send iodef reports)\nexample.com.  CAA 0 iodef &quot;mailto:cert-notify@example.com&quot;\nexample.com.  CAA 0 iodef &quot;https:\/\/caa.example.com\/report&quot;\n\n; Lock issuance to a specific Let\u2019s Encrypt account (Let\u2019s Encrypt supports this)\nexample.com.  CAA 0 issue &quot;letsencrypt.org; accounturi=https:\/\/acme-v02.api.letsencrypt.org\/acme\/acct\/12345678&quot;\n<\/code><\/pre>\n<p>A quick story from the trenches: one of my clients had a clean wildcard policy at the apex but forgot that a subdomain pointed to a vendor via CNAME. The vendor\u2019s domain had CAA records authorizing their preferred CA. Because the CAA check follows the CNAME target in addition to checking the queried name and its parents, the effective policy included the vendor\u2019s allowance. Net result: a certificate issued through the vendor\u2019s CA even though the parent zone intended to restrict it. The lesson I took away\u2014and now repeat often\u2014is to put explicit CAA records exactly where you care most, especially on hostnames that CNAME to third parties, and use <strong>iodef<\/strong> to keep your eyes on the system.<\/p>\n<h2 id=\"section-4\"><span id=\"Lets_Encrypt_and_ZeroSSL_getting_authorization_right\">Let\u2019s Encrypt and ZeroSSL: getting authorization right<\/span><\/h2>\n<p>Most folks I work with authorize at least two CAs for resilience\u2014typically Let\u2019s Encrypt and ZeroSSL\u2014so their ACME automation has a graceful fallback. With CAA, the \u201cblessings\u201d look like you\u2019d expect:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  CAA 0 issue &quot;letsencrypt.org&quot;\nexample.com.  CAA 0 issue &quot;zerossl.com&quot;\nexample.com.  CAA 0 issuewild &quot;letsencrypt.org&quot;\nexample.com.  CAA 0 issuewild &quot;zerossl.com&quot;\n<\/code><\/pre>\n<p>Now add nuance. Let\u2019s Encrypt supports an <em>accounturi<\/em> parameter, which lets you restrict issuance to a specific ACME account. This is wildly useful when multiple teams or vendors run ACME against the same domain. If you\u2019ve ever had that nervous feeling that someone, somewhere, might be automating a cert without telling you, <em>accounturi<\/em> is how you sleep better at night.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com.  CAA 0 issue &quot;letsencrypt.org; accounturi=https:\/\/acme-v02.api.letsencrypt.org\/acme\/acct\/12345678&quot;\n<\/code><\/pre>\n<p>ZeroSSL, in my experience, behaves well with standard <em>issue<\/em> and <em>issuewild<\/em> tags using <em>zerossl.com<\/em> as the value. If you\u2019re curious about the finer points, you can skim <a href=\"https:\/\/letsencrypt.org\/docs\/caa\/\" rel=\"nofollow noopener\" target=\"_blank\">Let\u2019s Encrypt\u2019s CAA guidance<\/a> and <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8659\" rel=\"nofollow noopener\" target=\"_blank\">the updated CAA RFC 8659<\/a> for background, and then verify what your specific tooling and provider support in practice. A tiny test zone\u2014and watching a couple of live ACME runs\u2014teaches more than a dozen docs.<\/p>\n<p>One approach I like for production is pairing a resilient ACME client configuration with a conservative CAA policy. The automation tries Let\u2019s Encrypt first, then falls back to ZeroSSL when needed. The CAA allows both, but the system naturally prefers the first. If you want to see how that looks in the real world, I wrote about <a href=\"https:\/\/www.dchost.com\/blog\/en\/acme-otomasyonunda-yedekli-ca-nasil-kurulur-acme-sh-ile-lets-encrypt-%e2%86%92-zerossl-fallback-oran-limitlerine-karsi-guvenli-olcekleme\/\">redundant ACME automation with acme.sh and a Let\u2019s Encrypt \u2192 ZeroSSL fallback<\/a> and how it reduces stress around rate limits and outages.<\/p>\n<h2 id=\"section-5\"><span id=\"Getting_the_wildcard_story_straight_issue_vs_issuewild\">Getting the wildcard story straight: issue vs issuewild<\/span><\/h2>\n<p>If CAA has a \u201cgotcha\u201d that bites people regularly, it\u2019s this: <strong>wildcards are their own world<\/strong>. A domain can happily authorize Let\u2019s Encrypt via <em>issue<\/em> and still fail wildcard issuance because <em>issuewild<\/em> wasn\u2019t included. And it\u2019s the kind of problem you don\u2019t notice until renewal day at 2 a.m.<\/p>\n<p>I\u2019ve developed a checklist for myself. First, explicitly allow the CA for non-wildcard with <em>issue<\/em>. Second, explicitly allow the CA for wildcard with <em>issuewild<\/em>. Third, decide how strict you want to be about denial by adding <em>issue &#8220;;&#8221;<\/em> and <em>issuewild &#8220;;&#8221;<\/em> after your allows, especially on zones where you don\u2019t want surprise issuers creeping in via a CNAME target. Fourth, make sure your ACME automation actually requests wildcards correctly\u2014DNS\u201101 is your friend here\u2014and that your DNS provider\u2019s API is smooth enough to handle TXT updates quickly.<\/p>\n<p>There\u2019s an interesting interaction worth highlighting. When a CA evaluates CAA, it checks the requested name, walks up the parent chain, and follows any CNAME target for additional policy. That means permissions can stack up in ways you might not expect. If a subdomain CNAMEs to a third party, and that third party authorizes a CA for wildcard issuance on their target zone, the effective policy for your exact hostname could end up allowing issuance even if your apex tried to be restrictive. That isn\u2019t a bug; it\u2019s how the spec resolves policy from multiple places. My habit is to place explicit CAA records on any hostname that matters, not only at the apex.<\/p>\n<h2 id=\"section-6\"><span id=\"iodef_the_unsung_hero_that_keeps_you_in_the_loop\">iodef: the unsung hero that keeps you in the loop<\/span><\/h2>\n<p>iodef is a little like turning on motion-activated lights in your backyard. Most nights, nothing happens. But if something does move, you get a ping. With CAA, you can provide an email address and\/or an HTTPS endpoint where CAs send notifications about policy violations or similar events. When you\u2019re doing controlled issuance\u2014especially in bigger orgs\u2014those \u201chey, we tried to issue and couldn\u2019t\u201d notes can save hours of head-scratching.<\/p>\n<p>I like to set both email and HTTPS. Email is timeless; it lands where people are. The HTTPS endpoint gives you a place to collect and analyze events if you want to get fancy later. My bias is to keep it simple: an internal webhook that logs to the same place as deployment events. When something goes wrong in cert land, I want it sitting next to my operational timeline, not buried in a separate system.<\/p>\n<pre class=\"language-python line-numbers\"><code class=\"language-python\">example.com.  CAA 0 iodef &quot;mailto:cert-notify@example.com&quot;\nexample.com.  CAA 0 iodef &quot;https:\/\/caa.example.com\/report&quot;\n<\/code><\/pre>\n<p>If you want a quick reference that stays close to the practical day-to-day, <a href=\"https:\/\/developers.cloudflare.com\/dns\/manage-dns-records\/reference\/caa-records\/\" rel=\"nofollow noopener\" target=\"_blank\">Cloudflare\u2019s practical CAA record reference<\/a> does a good job walking through the formats. The rules are simple, but the context\u2014especially once CNAMEs and subdomain overrides enter the chat\u2014benefits from being spelled out in examples.<\/p>\n<h2 id=\"section-7\"><span id=\"A_calm_multiCA_strategy_that_just_works\">A calm multi\u2011CA strategy that just works<\/span><\/h2>\n<p>The simplest strategy I\u2019ve found over the years is this: authorize two CAs you actually use, make your ACME automation prefer one and fall back to the other, and write CAA in a way that matches that plan. In most cases, that means Let\u2019s Encrypt first, ZeroSSL second. Wildcards included. And then a soft fence around your property using <em>issue &#8220;;&#8221;<\/em> and <em>issuewild &#8220;;&#8221;<\/em> after the permissions you do want.<\/p>\n<p>Why two CAs? Three reasons I see in the real world. First, rate limits. Even with careful staging, busy fleets can run hot now and then. Second, outages. Rare, but when they happen, it\u2019s nice not to be stuck. Third, policy changes. If one CA tightens something that hits your architecture, you have breathing room while you adjust. The operational cost of authorizing two CAs in CAA is virtually zero, and it buys you a lot of calm.<\/p>\n<p>When I set this up for teams, I encourage two small habits. One, put your CAA records next to the automation that depends on them. If your compose or Terraform is provisioning an ACME client, let it also declare the CAA you need. Two, test issuance deliberately from both CAs before you need it. It\u2019s like testing backups: doing it when the house is on fire is not the mood you want.<\/p>\n<p>Another note from experience: pay attention to DNS propagation and negative caching. If you change CAA and immediately kick off issuance, the CA\u2019s resolvers might still be seeing an older view. Keep TTLs reasonable, and give yourself a short grace window before renewals. When someone tells me \u201cit failed, then it worked an hour later,\u201d my first suspect is propagation.<\/p>\n<h2 id=\"section-8\"><span id=\"Implementation_patterns_and_the_little_traps\">Implementation patterns and the little traps<\/span><\/h2>\n<h3><span id=\"Start_at_the_apex_then_secure_the_edges\">Start at the apex, then secure the edges<\/span><\/h3>\n<p>Most zones should carry CAA at the apex. That covers the majority of names. But remember that subdomains can override or add to the apex policy, and CNAME targets can contribute their own CAA. If you have \u201cspecial\u201d hostnames\u2014CDN endpoints, vendor integrations, anything that\u2019s a linchpin\u2014put explicit CAA there as well. It\u2019s not much work, and it keeps surprises to a minimum.<\/p>\n<h3><span id=\"Be_explicit_about_wildcards\">Be explicit about wildcards<\/span><\/h3>\n<p>Even if you don\u2019t use wildcards today, consider writing <em>issuewild<\/em> on day one\u2014either authorizing the CA you plan to use or explicitly denying with an empty value. That way you won\u2019t be guessing at two in the morning when a new team asks why their wildcard order won\u2019t go through.<\/p>\n<h3><span id=\"Use_account-level_constraints_where_it_helps\">Use account-level constraints where it helps<\/span><\/h3>\n<p>If your organization runs multiple ACME accounts for separation of duties, use <em>accounturi<\/em> where supported to tighten who can request what. It\u2019s not mandatory, and many healthy setups run fine without it. But when you need traceability\u2014who requested which cert and from where\u2014tying CAA to an account is a nice tool to have.<\/p>\n<h3><span id=\"Remember_the_CNAME_and_parent_walk\">Remember the CNAME and parent walk<\/span><\/h3>\n<p>When a CA evaluates CAA, it looks at the exact hostname, then walks up the parent chain until it finds relevant records, and also follows any CNAME target to consider that domain\u2019s CAA. The net effect can surprise folks who relied on an apex \u201cdeny\u201d while a subdomain CNAMEs into a vendor that explicitly <em>allows<\/em> issuance for its service. This is one reason I like to keep iodef notifications on and place specific CAA on sensitive subdomains.<\/p>\n<h3><span id=\"Propagation_TTLs_and_negative_answers\">Propagation, TTLs, and negative answers<\/span><\/h3>\n<p>CAA behaves like any other DNS record when it comes to caching. If you remove an allow or add a deny, caches can hold the previous answer for a bit. When I\u2019m changing policy near renewal, I\u2019ll lower TTLs ahead of time and switch policy during a quiet window. It\u2019s not about fear; it\u2019s just avoiding unnecessary flakiness during renewals.<\/p>\n<h3><span id=\"Testing_without_drama\">Testing without drama<\/span><\/h3>\n<p>My favorite quick test is good old <em>dig<\/em>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig +short CAA example.com\n\n; For a specific host\ndig +short CAA app.example.com\n<\/code><\/pre>\n<p>Then I\u2019ll do a dry\u2011run issuance with my ACME client against a staging endpoint to confirm behavior. Watching the logs while the CA queries your DNS is oddly satisfying. You see exactly where it checks, what it finds, and why it proceeds or refuses.<\/p>\n<p>If you ever want a second opinion on the record formats and semantics, two pieces worth bookmarking are <a href=\"https:\/\/letsencrypt.org\/docs\/caa\/\" rel=\"nofollow noopener\" target=\"_blank\">Let\u2019s Encrypt\u2019s CAA guidance<\/a> and <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8659\" rel=\"nofollow noopener\" target=\"_blank\">RFC 8659<\/a>. They\u2019re concise enough that you can dip in, confirm a detail, and pop back out without losing your afternoon.<\/p>\n<h2 id=\"section-9\"><span id=\"A_quick_word_on_DNSSEC_and_CAA_trust\">A quick word on DNSSEC and CAA trust<\/span><\/h2>\n<p>You don\u2019t need DNSSEC for CAA to work, but pairing them is like putting good locks on a sturdy door. When your DNS is signed and the world can validate those signatures, you reduce the risk of someone spoofing answers to a CA. In practice, I\u2019ve seen teams roll out CAA first and add DNSSEC once the DNS tooling and processes are comfortable. The two complement each other nicely. If you\u2019re doing higher\u2011sensitivity workloads, it\u2019s a natural part of the journey.<\/p>\n<h2 id=\"section-10\"><span id=\"Wrapping_it_all_up_CAA_as_your_quiet_policy_engine\">Wrapping it all up: CAA as your quiet policy engine<\/span><\/h2>\n<p>Let me circle back to that Thursday night. The fix turned out to be two lines of CAA for <em>issuewild<\/em>, a couple of iodef contacts, and a small note in the runbook. It wasn\u2019t heroic. But it turned a brittle corner of the system into something calm and predictable. That\u2019s the best outcome in this craft.<\/p>\n<p>If you\u2019re just getting started, begin with the simple shape: authorize Let\u2019s Encrypt and ZeroSSL for both normal and wildcard issuance, add iodef to keep yourself in the loop, and consider a gentle deny to discourage unexpected issuers. If you\u2019re running at scale, layer on account-level constraints where helpful, test both CAs in your automation, and keep an eye on CNAMEs that point to vendors. None of it is complicated; it\u2019s just a handful of careful choices you make once and then enjoy for months.<\/p>\n<p>Hope this was helpful. If you want a practical tour of failover in action, I\u2019ve shared how I run <a href=\"https:\/\/www.dchost.com\/blog\/en\/acme-otomasyonunda-yedekli-ca-nasil-kurulur-acme-sh-ile-lets-encrypt-%e2%86%92-zerossl-fallback-oran-limitlerine-karsi-guvenli-olcekleme\/\">redundant ACME automation with acme.sh and a Let\u2019s Encrypt \u2192 ZeroSSL fallback<\/a>. Here\u2019s to fewer late nights, predictable renewals, and certificates that just show up when you need them. See you in the next post.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 The moment CAA clicked for me2 What CAA really is (and why you\u2019ll grow to love it)3 The anatomy of a CAA record: issue, issuewild, iodef (and friends)4 Let\u2019s Encrypt and ZeroSSL: getting authorization right5 Getting the wildcard story straight: issue vs issuewild6 iodef: the unsung hero that keeps you in the loop7 A [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1894,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-1893","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\/1893","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=1893"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1893\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/1894"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=1893"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=1893"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=1893"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}