ipng/ipng.ch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Replace all post_url with Hugo ref blocks

Browse Source
This commit is contained in:
Pim van Pelt
2024-08-05 01:43:55 +02:00
parent c1f1775c91
commit a2f10236a3
56 changed files with 221 additions and 241 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
content/articles/2023-03-24-lego-dns01.md
View File

@ -6,10 +6,10 @@ title: 'Case Study: Let''s Encrypt DNS-01'
Last week I shared how IPng Networks deployed a loadbalanced frontend cluster of NGINX webservers
that have public IPv4 / IPv6 addresses, but talk to a bunch of internal webservers that are in a
private network which isn't directly connected to the internet, so called _IPng Site Local_
[[ref]({%post_url 2023-03-11-mpls-core %})] with addresses **198.19.0.0/16** and
[[ref]({{< ref "2023-03-11-mpls-core" >}})] with addresses **198.19.0.0/16** and
**2001:678:d78:500::/56**.
I wrote in [[that article]({% post_url 2023-03-17-ipng-frontends %})] that IPng will be using
I wrote in [[that article]({{< ref "2023-03-17-ipng-frontends" >}})] that IPng will be using
_ACME_ HTTP-01 validation, which asks the certificate authority, in this case Let's Encrypt, to
contact the webserver on a well-known URI for each domain that I'm requesting a certificate for.
Unsurprisingly, several folks reached out to me asking "well what about DNS-01", and one sentence
@ -30,7 +30,7 @@ wrong, and that using DNS-01 ***is*** relatively simple after all.
I've installed three frontend NGINX servers (running at Coloclue AS8283, IPng AS8298 and IP-Max
AS25091), and one LEGO certificate machine (running in the internal _IPng Site Local_ network).
In the [[previous article]({% post_url 2023-03-17-ipng-frontends %})], I described the setup and
In the [[previous article]({{< ref "2023-03-17-ipng-frontends" >}})], I described the setup and
the use of Let's Encrypt with HTTP-01 challenges. I'll skip that here.
#### HTTP-01 vs DNS-01