letsencrypt · ludekjanda · Mar 5, 2026 · Mar 5, 2026
diff --git a/content/da/docs/a-warm-welcome-to-asn1-and-der.md b/content/da/docs/a-warm-welcome-to-asn1-and-der.md
@@ -931,7 +931,7 @@ MIIFajCCBFKgAwIBAgISA6HJW9qjaoJoMn8iU8vTuiQ2MA0GCSqGSIb3DQEBCwUA
 
 Nu ved du nok til at forklare hvorfor! Et [certifikat er et SEKVENS](https://tools.ietf.org/html/rfc5280#page-116), så det vil starte med byte 0x30. De næste bytes er feltet [længde ](#length). Certifikater er næsten altid mere end 127 bytes, så længden feltet skal bruge den lange form af længden. Det betyder, at den første byte vil være 0x80 + N, hvor N er antallet af længdebytes der skal følges. N er næsten altid 2, da det er hvor mange bytes det tager at indkode længder fra 128 til 65535, og næsten alle certifikater har længder i denne rækkevidde.
 
-Så nu ved vi, at de første to bytes af DER kodning af et certifikat er 0x30 0x82. [PEM kodning](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) anvender [base64](https://en.wikipedia.org/wiki/Base64), som koder 3 bytes af binære input i 4 ASCII tegn af output. Eller for at sige det anderledes: base64 forvandler 24 bits binær input til 4 ASCII-tegn output, med 6 bits af input tildelt til hvert tegn. Vi ved, hvad de første 16 bits af hvert certifikat vil være. For at bevise, at de første tegn af (næsten) hvert certifikat vil være "MII", vi har brug for to til at se på de næste 2 bit. Disse vil være de mest betydningsfulde bits af den mest betydningsfulde byte af de to længde bytes. Vil disse bits nogensinde blive sat til 1? Ikke medmindre certifikatet er mere end 16,383 bytes langt! Så vi kan forudsige, at de første tegn i et PEM-certifikat altid vil være det samme. Prøv det selv:
+Så nu ved vi, at de første to bytes af DER kodning af et certifikat er 0x30 0x82. [PEM kodning](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) anvender [base64](https://en.wikipedia.org/wiki/Base64), som koder 3 bytes af binære input i 4 ASCII tegn af output. Eller for at sige det anderledes: base64 forvandler 24 bits binær input til 4 ASCII-tegn output, med 6 bits af input tildelt til hvert tegn. Vi ved, hvad de første 16 bits af hvert certifikat vil være. For at bevise, at de første tegn af (næsten) hvert certifikat vil være "MII", har vi brug for to til at se på de næste 2 bit. Disse vil være de mest betydningsfulde bits af den mest betydningsfulde byte af de to længde bytes. Vil disse bits nogensinde blive sat til 1? Ikke medmindre certifikatet er mere end 16,383 bytes langt! Så vi kan forudsige, at de første tegn i et PEM-certifikat altid vil være det samme. Prøv det selv:
 
 
 

diff --git a/content/da/docs/challenge-types.md b/content/da/docs/challenge-types.md
@@ -1,7 +1,7 @@
 ---
 title: Udfordringstyper
 slug: challenge-types
-lastmod: 2025-12-03
+lastmod: 2026-02-12
 show_lastmod: 1
 ---
 
@@ -26,7 +26,7 @@ Fordele:
 Ulemper:
 
 - Det virker ikke, hvis din ISP blokke port 80 (dette er sjældent, men nogle få internetudbydere gør dette).
-- Let's Encrypt lader dig ikke bruge denne udfordring til at udstede wildcard certifikater.
+- Denne udfordring kan ikke bruges til at udstede wildcard certifikater.
 - Hvis du har flere webservere, skal du sørge for, at filen er tilgængelig på dem alle.
 
 # DNS-01 challenge

diff --git a/content/da/docs/glossary.md b/content/da/docs/glossary.md
@@ -65,7 +65,7 @@ Note for translators:
 
 {{% def id="store" name="Certificate Store" %}} En certifikatsamling som indeholder med betroede [Rod certifikater](#def-root). Styresystemer (såsom Windows, Android eller Debian) og [webbrowsere](#def-web-browser) (såsom Firefox) vedligeholder en certifikatsamling. Browsere uden egen certifikatsamling anvender operativsystemernes certifikatsamling. [Certifikater](#def-leaf) leveret af [Let's Encrypt](#def-LE) er [betroede af de fleste certifikatsamlinger](/certificates). {{% /def %}}
 
-{{% def id="subject" name="Certificate subject" %}} Feltet "Subject" i et certifikatfelt angiver, hvad certifikatet omhandler. Dette indeholder ofte felter som [Common Name](#def-CN), Country og Organization. {{% /def %}}
+{{% def id="subject" name="Certificate subject" %}} Feltet "Emne" i et certifikatfelt angiver, hvad certifikatet omhandler. Dette indeholder ofte felter som [Common Name](#def-CN), Country og Organization. {{% /def %}}
 
 {{% def id="CT" name="Certificate Transparency" abbr="CT" %}} For at forbedre sikkerheden, skal certifikater (eller [præ-certfikater](#def-precertificate)) offentliggøres i Certifikat Gennemsigtighed Logs: https://www.certificate-transparency.org/. [Let's Encrypt](#def-LE) genererer og publicerer [precertificates](#def-precertificate), og indeholder i det efterfølgende [certifikat](#def-leaf) en liste over [SCT](#def-SCT) for præ-certifikatet. Nogle [browsere](#def-web-browser), såsom Google Chrome, kræver tilstedeværelsen af dette verificerbare løfte for at validere certifikatet. [Wikipedia](https://en.wikipedia.org/wiki/Certificate_Transparency) {{% /def %}}
 

diff --git a/content/da/docs/profiles.md b/content/da/docs/profiles.md
@@ -1,7 +1,7 @@
 ---
 title: Profiler
 slug: profiles
-lastmod: 2025-12-19
+lastmod: 2026-02-11
 show_lastmod: false
 ---
 
@@ -26,7 +26,7 @@ Den klassiske profil er standardprofilen valgt for alle ordrer, som ikke anmoder
 | [Ordre Livstid](#order-lifetime)                                     | 7 dage                                    |
 | [Certificate Common Name](#certificate-common-name)                  | <a href="#footnote-1">Ja<sup>\*</sup></a> |
 | [Key Encipherment KU](#key-encipherment-key-usage)                   | <a href="#footnote-2">Ja<sup>†</sup></a>  |
-| [TLS Client Auth EKU](#tls-client-authentication-extended-key-usage) | <a href="#footnote-3">Ja<sup>‡</sup></a>  |
+| [TLS Client Auth EKU](#tls-client-authentication-extended-key-usage) | Nej                                       |
 | [Emne Nøgle ID](#subject-key-identifier-extension)                   | Ja                                        |
 | [Gyldighedsperiode](#validity-period)                                | 90 dage                                   |
 | [Revocation Information](#revocation-information)                    | CRL                                       |
@@ -37,9 +37,6 @@ Den klassiske profil er standardprofilen valgt for alle ordrer, som ikke anmoder
 
 <sup id="footnote-2">†</sup>: Kun inkluderet for certifikater med RSA offentlige nøgler.
 
-<sup id="footnote-3">‡</sup>: Indtil 11. Februar 2026. Se [udfasnings tidslinje oplysninger](/2025/05/14/ending-tls-client-authentication/) for en fuld tidslinje.
-
-</div>
 <div class="boxed">
 
 ## tlsserver
@@ -92,18 +89,16 @@ Vi anbefaler denne profil for dem, der fuldt ud stoler på deres automatisering
 
 ## tlsclient
 
-Den tlsclient profil er _for nærværende_ identisk med den klassiske profil. Men
-som [annonceret på vores blog](/2025/05/14/ending-tls-client-authentication):
+Certifikater udstedt med tlsclient profil indeholder TLS Client Auth EKU.
+Den er ellers identisk med den klassiske profil.
 
-- 11. februar 2026 vil TLS Client Auth EKU blive fjernet fra den klassiske
-      profil, men vil forblive i denne profil, og
-- 13. maj 2026 vil denne profil ophøre med at eksistere.
+Men som [annonceret på vores blog](/2025/05/14/ending-tls-client-authentication),
+denne profil vil ophøre med at eksistere den 13. maj 2026.
 
 Denne profil findes alene med det formål at give abonnenter, der har brug for adgang til
 til TLS Client Auth certifikater til at beholde den EKU i lidt længere tid at
 lette deres overgang til en TLS Server Auth-only verden. Hvis du ikke
-specifikt har brug for TLS Client Auth EKU, eller hvis du har brug for det, men er i stand til at
-migrere væk fra den inden februar 2026, så kan og skal du sikkert ignorere
+specifikt har brug for TLS-klienten Auth EKU, kan og bør du roligt ignorere
 denne profil.
 
 | Egenskaber                                                           | Værdi                                     |

diff --git a/content/da/upcoming-features.md b/content/da/upcoming-features.md
@@ -1,7 +1,7 @@
 ---
 title: Kommende Funktioner
 slug: upcoming-features
-lastmod: 2025-12-17
+lastmod: 2026-02-11
 show_lastmod: 1
 ---
 
@@ -11,7 +11,7 @@ For meddelelser om kommende ændringer, venligst [abonnér på postlisten Teknis
 
 ## Fjernelse af TLS Client Authentication EKU
 
-11. feb 2026 agter vi at [fjerne "TLS-klientgodkendelse" Extended Key Usage (EKU)](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/) fra vores standard certifikatprofil. Før denne dato vil vi tilbyde en alternativ profil, som stadig vil indeholde den EKU men bemærk, at dette vil være en midlertidig stop-gap for kunder, der har brug for mere tid til at migrere væk fra at have brug for det: at alternativ profil vil gå væk den 13. maj, 2026.
+11. feb 2026 agter vi at [fjerne "TLS-klientgodkendelse" Extended Key Usage (EKU)](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/) fra vores standard certifikatprofil. Som et midlertidigt stop-gap for kunder, der har brug for mere tid til at migrere, har vi en [tlsclient](https://letsencrypt.org/docs/profiles/#tlsclient) profil tilgængelig indtil 13. maj 2026.
 
 ## Reduceret certifikatet levetider til 45 dage
 

diff --git a/i18n/da.toml b/i18n/da.toml
@@ -380,10 +380,10 @@ other = "En nyere opdateret side er tilgængelig på engelsk"
 other = "Blog"
 
 [post_support_heading]
-other = "Support Our Work"
+other = "Støt Vores Arbejde"
 
 [post_support_body_html]
-other = "ISRG is a 501(c)(3) nonprofit organization that is 100% supported through the generosity of those who share our vision for ubiquitous, open Internet security. If you'd like to support our work, please consider <a href=\"https://www.abetterinternet.org/getinvolved/\">getting involved</a>, <a href=\"/donate/\">donating</a>, or encouraging your company to <a href=\"https://www.abetterinternet.org/sponsor/\">become a sponsor</a>."
+other = 'ISRG er en 501(c)(3) nonprofit organisation, der er 100% støttet gennem generøsitet af dem, der deler vores vision for allestedsnærværdig, åben internetsikkerhed. Hvis du vil støtte vores arbejde, så overvej venligst <a href="https://www.abetterinternet.org/getinvolved/">at blive involveret</a>, <a href="/donate/">donere</a>eller tilskynde din virksomhed til <a href="https://www.abetterinternet.org/sponsor/">blive en sponsor</a>.'
 
 [donate_get_involved_button]
 other = "Bliv en del af det"
@@ -476,7 +476,7 @@ other = "Andre måder at give"
 other = "VEJE TIL AT GIVE"
 
 [donate_page_funding_details_stat_text]
-other = "Enable our work at Let's Encrypt through your charitable contribution."
+other = "Muliggør vores arbejde på Let's Encrypt gennem dit velgørende bidrag."
 
 [donate_page_funding_details_why_support_heading]
 other = "HVORFOR STØTTE?"
Original file line number	Diff line number	Diff line change
Expand Up		@@ -931,7 +931,7 @@ MIIFajCCBFKgAwIBAgISA6HJW9qjaoJoMn8iU8vTuiQ2MA0GCSqGSIb3DQEBCwUA

		Nu ved du nok til at forklare hvorfor! Et [certifikat er et SEKVENS](https://tools.ietf.org/html/rfc5280#page-116), så det vil starte med byte 0x30. De næste bytes er feltet [længde ](#length). Certifikater er næsten altid mere end 127 bytes, så længden feltet skal bruge den lange form af længden. Det betyder, at den første byte vil være 0x80 + N, hvor N er antallet af længdebytes der skal følges. N er næsten altid 2, da det er hvor mange bytes det tager at indkode længder fra 128 til 65535, og næsten alle certifikater har længder i denne rækkevidde.

		Så nu ved vi, at de første to bytes af DER kodning af et certifikat er 0x30 0x82. [PEM kodning](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) anvender [base64](https://en.wikipedia.org/wiki/Base64), som koder 3 bytes af binære input i 4 ASCII tegn af output. Eller for at sige det anderledes: base64 forvandler 24 bits binær input til 4 ASCII-tegn output, med 6 bits af input tildelt til hvert tegn. Vi ved, hvad de første 16 bits af hvert certifikat vil være. For at bevise, at de første tegn af (næsten) hvert certifikat vil være "MII", vi har brug for to til at se på de næste 2 bit. Disse vil være de mest betydningsfulde bits af den mest betydningsfulde byte af de to længde bytes. Vil disse bits nogensinde blive sat til 1? Ikke medmindre certifikatet er mere end 16,383 bytes langt! Så vi kan forudsige, at de første tegn i et PEM-certifikat altid vil være det samme. Prøv det selv:
		Så nu ved vi, at de første to bytes af DER kodning af et certifikat er 0x30 0x82. [PEM kodning](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) anvender [base64](https://en.wikipedia.org/wiki/Base64), som koder 3 bytes af binære input i 4 ASCII tegn af output. Eller for at sige det anderledes: base64 forvandler 24 bits binær input til 4 ASCII-tegn output, med 6 bits af input tildelt til hvert tegn. Vi ved, hvad de første 16 bits af hvert certifikat vil være. For at bevise, at de første tegn af (næsten) hvert certifikat vil være "MII", har vi brug for to til at se på de næste 2 bit. Disse vil være de mest betydningsfulde bits af den mest betydningsfulde byte af de to længde bytes. Vil disse bits nogensinde blive sat til 1? Ikke medmindre certifikatet er mere end 16,383 bytes langt! Så vi kan forudsige, at de første tegn i et PEM-certifikat altid vil være det samme. Prøv det selv:



Expand Down