<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>certificates</title>
    <link rel="self" type="application/atom+xml" href="https://links.pgmac.net.au/guest/tags/224/feed"/>
    <updated>2026-05-07T01:08:21+10:00</updated>
    <id>https://links.pgmac.net.au/guest/tags/224/feed</id>
            <entry>
            <id>https://links.pgmac.net.au/links/1529</id>
            <title type="text"><![CDATA[DNS-Persist-01: A New Model for DNS-Based Challenge Validation]]></title>
            <link rel="alternate" href="https://letsencrypt.org/2026/02/18/dns-persist-01.html" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/1529"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[When you request a certificate from Let’s Encrypt, our servers validate that you control the hostnames in that certificate using ACME challenges. For subscribers who need wildcard certificates or who prefer not to expose infrastructure to the public Internet, the DNS-01 challenge type has long been the only choice. DNS-01 works well. It is widely supported and battle-tested, but it comes with operational costs: DNS propagation delays, recurring DNS updates at renewal time, and automation that often requires distributing DNS credentials throughout your infrastructure.]]>
            </summary>
            <updated>2026-02-22T14:11:13+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/1416</id>
            <title type="text"><![CDATA[Certificate Transparency Log Explorer]]></title>
            <link rel="alternate" href="https://certs.swerdlow.dev" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/1416"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[Browse Certificate Transparency logs]]>
            </summary>
            <updated>2026-01-24T13:20:40+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/1398</id>
            <title type="text"><![CDATA[6-Day and IP Address Certificates Are Generally Available]]></title>
            <link rel="alternate" href="https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/1398"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[Short-lived and IP address certificates are now generally available from Let’s Encrypt. These certificates are valid for 160 hours, just over six days. In order to get a short-lived certificate subscribers simply need to select the ‘shortlived’ certificate profile in their ACME client.
Short-lived certificates improve security by requiring more frequent validation and reducing reliance on unreliable revocation mechanisms. If a certificate’s private key is exposed or compromised, revocation has historically been the way to mitigate damage prior to the certificate’s expiration. Unfortunately, revocation is an unreliable system so many relying parties continue to be vulnerable until the certificate expires, a period as long as 90 days. With short-lived certificates that vulnerability window is greatly reduced.]]>
            </summary>
            <updated>2026-01-28T09:57:42+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/1285</id>
            <title type="text"><![CDATA[Decreasing Certificate Lifetimes to 45 Days]]></title>
            <link rel="alternate" href="https://letsencrypt.org/2025/12/02/from-90-to-45.html" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/1285"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.]]>
            </summary>
            <updated>2025-12-08T10:38:07+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/1094</id>
            <title type="text"><![CDATA[Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1]]></title>
            <link rel="alternate" href="https://blog.cloudflare.com/unauthorized-issuance-of-certificates-for-1-1-1-1/" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/1094"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[Unauthorized TLS certificates were issued for 1.1.1.1 by a Certification Authority without permission from Cloudflare. These rogue certificates have now been revoked. Read our blog to see how this could affect you.]]>
            </summary>
            <updated>2025-09-05T06:16:26+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/855</id>
            <title type="text"><![CDATA[SSL/TLS certificate lifespans reduced to 47 days by 2029]]></title>
            <link rel="alternate" href="https://www.bleepingcomputer.com/news/security/ssl-tls-certificate-lifespans-reduced-to-47-days-by-2029/" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/855"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[The CA/Browser Forum has voted to significantly reduce the lifespan of SSL/TLS certificates over the next 4 years, with a final lifespan of just 47 days starting in 2029.]]>
            </summary>
            <updated>2025-05-28T01:04:11+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/803</id>
            <title type="text"><![CDATA[Bug 1950144]]></title>
            <link rel="alternate" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1950144" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/803"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[ASSIGNED (dcbugzillaresponse) in CA Program - CA Certificate Root Program. Last updated 2025-05-27.]]>
            </summary>
            <updated>2025-05-28T00:56:05+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/662</id>
            <title type="text"><![CDATA[nh2/internal-contstrained-pki]]></title>
            <link rel="alternate" href="https://github.com/nh2/internal-contstrained-pki" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/662"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[Safely shareable TLS root CA for .internal networks using Name Constraints - nh2/internal-contstrained-pki]]>
            </summary>
            <updated>2026-01-19T04:00:55+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/491</id>
            <title type="text"><![CDATA[Certificate Revocation Incident | DigiCert]]></title>
            <link rel="alternate" href="https://www.digicert.com/support/certificate-revocation-incident" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/491"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[]]>
            </summary>
            <updated>2025-12-18T04:00:32+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/487</id>
            <title type="text"><![CDATA[All I Know About Certificates -- Certificate Authority | PixelsTech]]></title>
            <link rel="alternate" href="https://www.pixelstech.net/article/1722045726-All-I-Know-About-Certificates----Certificate-Authority" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/487"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[CLIENTS,WEBSITE,CERTIFICATE,SSL CERTIFICATE.One of the crucial steps in the TLS handshake is for the server to prove its identity to the client. While there is plenty of content explaining the principles of the handshake, there&amp;#039;s less informati]]>
            </summary>
            <updated>2025-12-13T04:00:10+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/301</id>
            <title type="text"><![CDATA[https://aws.amazon.com/blogs/security/how-to-verify-aws-kms-asymmetric-key-signatures-locally-with-openssl/?sc_channel=sm&amp;amp;sc_campaign=AWSSecurity_Services&amp;amp;sc_publisher=TWITTER&amp;amp;sc_country=Security&amp;amp;sc_geo=GLOBAL&amp;amp;sc_outcome=adoption&amp;amp;trk=AWSSecurity_Services_TWITTER&amp;amp;linkId=86699220]]></title>
            <link rel="alternate" href="https://aws.amazon.com/blogs/security/how-to-verify-aws-kms-asymmetric-key-signatures-locally-with-openssl/?sc_channel=sm&amp;sc_campaign=AWSSecurity_Services&amp;sc_publisher=TWITTER&amp;sc_country=Security&amp;sc_geo=GLOBAL&amp;sc_outcome=adoption&amp;trk=AWSSecurity_Services_TWITTER&amp;linkId=86699220" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/301"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[August 31, 2021: AWS KMS is replacing the term customer master key (CMK) with AWS KMS key and KMS key. The concept has not changed. To prevent breaking changes, AWS KMS is keeping some variations of this term. More info. In this post, I demonstrate a sample workflow for generating a digital signature within AWS […]]]>
            </summary>
            <updated>2026-01-19T06:00:13+10:00</updated>
        </entry>
            <entry>
            <id>https://links.pgmac.net.au/links/236</id>
            <title type="text"><![CDATA[PKI for busy people]]></title>
            <link rel="alternate" href="https://rehn.me/posts/pki-for-busy-people.html" />
            <link rel="via" type="application/atom+xml" href="https://links.pgmac.net.au/links/236"/>
            <author>
                <name><![CDATA[Paul Macdonnell]]></name>
            </author>
            <summary type="text">
                <![CDATA[]]>
            </summary>
            <updated>2025-12-24T16:00:07+10:00</updated>
        </entry>
    </feed>
