From a97115593c56d64fa7c5b3ddab0ecb0ae4131363 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 25 Aug 2025 09:55:40 +0000 Subject: [PATCH 01/12] Typo and readability fixes --- content/articles/2025-08-24-ctlog-3.md | 82 ++++++++++++++------------ 1 file changed, 44 insertions(+), 38 deletions(-) diff --git a/content/articles/2025-08-24-ctlog-3.md b/content/articles/2025-08-24-ctlog-3.md index 7495a2a..c7514b6 100644 --- a/content/articles/2025-08-24-ctlog-3.md +++ b/content/articles/2025-08-24-ctlog-3.md @@ -131,8 +131,9 @@ logs: ``` In the first configuration file, I'll tell _Sunlight_ (the write path component) to listen on port -`16420` and I'll tell _Skylight_ (the read path component) to listen on port `16421`. I've disabled -the automatic certificate renewals, and will handle SSL upstream: +`:16420` and I'll tell _Skylight_ (the read path component) to listen on port `:16421`. I've disabled +the automatic certificate renewals, and will handle SSL upstream. A few notes on this: + 1. Most importantly, I will be using a common frontend pool with a wildcard certificate for `*.ct.ipng.ch`. I wrote about [[DNS-01]({{< ref 2023-03-24-lego-dns01 >}})] before, it's a very convenient way for IPng to do certificate pool management. I will be sharing certificate for all log @@ -149,7 +150,7 @@ for Rennet, and a few days later, for Gouda, are operational this way. Skylight provides all the things I need to serve the data back, which is a huge help. The [[Static Log Spec](https://github.com/C2SP/C2SP/blob/main/static-ct-api.md)] is very clear on things like -compression, content-type, cache-control and other headers. Skylight makes this a breeze, as it read +compression, content-type, cache-control and other headers. Skylight makes this a breeze, as it reads a configuration file very similar to the Sunlight write-path one, and takes care of it all for me. ## TesseraCT @@ -157,16 +158,17 @@ a configuration file very similar to the Sunlight write-path one, and takes care {{< image width="10em" float="right" src="/assets/ctlog/tesseract-logo.png" alt="TesseraCT logo" >}} Good news came to our community on August 14th, when Google's TrustFabric team announced their Alpha -milestone of [[TesseraCT](https://blog.transparency.dev/introducing-tesseract)]. And the release +milestone of [[TesseraCT](https://blog.transparency.dev/introducing-tesseract)]. This release also moved the POSIX variant from experimental alongside the already further along GCP and AWS personalities. After playing around with it with Al and the team, I think I've learned enough to get -us going in a public instance. +us going in a public `tesseract-posix` instance. One thing I liked about Sunlight is its compact YAML file that described the pertinent bits of the system, and that I can serve any number of logs with the same process. On the other hand, TesseraCT can serve only one log per process. Both have pro's and con's, notably if any poisonous submission would be offered, Sunlight might take down all logs, while TesseraCT would only take down the log -receiving the offensive submission. On the other hand, maintaining separate processes is cumbersome. +receiving the offensive submission. On the other hand, maintaining separate processes is cumbersome, +and all log instances need to be meticulously configured. ### TesseraCT genconf @@ -179,6 +181,8 @@ Sunlight YAML configuration, and came up with a variant like this one: ``` ctlog@ctlog1:/ssd-vol0/enc/tesseract$ cat << EOF | tee tesseract-staging.yaml +listen: + - "[::]:8080" roots: /ssd-vol0/enc/tesseract/roots.pem logs: - shortname: lipase2025h2 @@ -205,11 +209,11 @@ private key, from which the _Log ID_ and _Public Key_ can be derived. So off I g ``` ctlog@ctlog1:/ssd-vol0/enc/tesseract$ tesseract-genconf -c tesseract-staging.yaml gen-key -Generated /ssd-vol0/enc/tesseract/keys/lipase2025h2.pem -Generated /ssd-vol0/enc/tesseract/keys/lipase2026h1.pem -Generated /ssd-vol0/enc/tesseract/keys/lipase2026h2.pem -Generated /ssd-vol0/enc/tesseract/keys/lipase2027h1.pem -Generated /ssd-vol0/enc/tesseract/keys/lipase2027h2.pem +Creating /ssd-vol0/enc/tesseract/keys/lipase2025h2.pem +Creating /ssd-vol0/enc/tesseract/keys/lipase2026h1.pem +Creating /ssd-vol0/enc/tesseract/keys/lipase2026h2.pem +Creating /ssd-vol0/enc/tesseract/keys/lipase2027h1.pem +Creating /ssd-vol0/enc/tesseract/keys/lipase2027h2.pem ``` Of course, if a file already exists at that location, it'll just print a warning like: @@ -226,16 +230,16 @@ of the logs: ``` ctlog@ctlog1:/ssd-vol0/enc/tesseract$ tesseract-genconf -c tesseract-staging.yaml gen-html -Generated /ssd-vol0/logs/lipase2025h2/data/index.html -Generated /ssd-vol0/logs/lipase2025h2/data/log.v3.json -Generated /ssd-vol0/logs/lipase2026h1/data/index.html -Generated /ssd-vol0/logs/lipase2026h1/data/log.v3.json -Generated /ssd-vol0/logs/lipase2026h2/data/index.html -Generated /ssd-vol0/logs/lipase2026h2/data/log.v3.json -Generated /ssd-vol0/logs/lipase2027h1/data/index.html -Generated /ssd-vol0/logs/lipase2027h1/data/log.v3.json -Generated /ssd-vol0/logs/lipase2027h2/data/index.html -Generated /ssd-vol0/logs/lipase2027h2/data/log.v3.json +Creating /ssd-vol0/logs/lipase2025h2/data/index.html +Creating /ssd-vol0/logs/lipase2025h2/data/log.v3.json +Creating /ssd-vol0/logs/lipase2026h1/data/index.html +Creating /ssd-vol0/logs/lipase2026h1/data/log.v3.json +Creating /ssd-vol0/logs/lipase2026h2/data/index.html +Creating /ssd-vol0/logs/lipase2026h2/data/log.v3.json +Creating /ssd-vol0/logs/lipase2027h1/data/index.html +Creating /ssd-vol0/logs/lipase2027h1/data/log.v3.json +Creating /ssd-vol0/logs/lipase2027h2/data/index.html +Creating /ssd-vol0/logs/lipase2027h2/data/log.v3.json ``` {{< image width="60%" src="/assets/ctlog/lipase.png" alt="TesseraCT Lipase Log" >}} @@ -253,12 +257,14 @@ from any other running log instance, so I'll implement a `gen-roots` command: ctlog@ctlog1:/ssd-vol0/enc/tesseract$ tesseract-genconf gen-roots \ --source https://tuscolo2027h1.sunlight.geomys.org --output production-roots.pem Fetching roots from: https://tuscolo2027h1.sunlight.geomys.org/ct/v1/get-roots -2025/08/25 08:24:58 Warning: Failed to parse certificate, skipping: x509: negative serial number +2025/08/25 08:24:58 Warning: Failed to parse certificate,carefully skipping: x509: negative serial number +Creating production-roots.pem Successfully wrote 248 certificates to tusc.pem (out of 249 total) ctlog@ctlog1:/ssd-vol0/enc/tesseract$ tesseract-genconf gen-roots \ --source https://navigli2027h1.sunlight.geomys.org --output testing-roots.pem Fetching roots from: https://navigli2027h1.sunlight.geomys.org/ct/v1/get-roots +Creating testing-roots.pem Successfully wrote 82 certificates to tusc.pem (out of 82 total) ``` @@ -297,16 +303,16 @@ I can now implement a `gen-env` command for my tool: ``` ctlog@ctlog1:/ssd-vol0/enc/tesseract$ tesseract-genconf -c tesseract-staging.yaml gen-env -Generated /ssd-vol0/logs/lipase2025h2/data/roots.pem -Generated /ssd-vol0/logs/lipase2025h2/data/.env -Generated /ssd-vol0/logs/lipase2026h1/data/roots.pem -Generated /ssd-vol0/logs/lipase2026h1/data/.env -Generated /ssd-vol0/logs/lipase2026h2/data/roots.pem -Generated /ssd-vol0/logs/lipase2026h2/data/.env -Generated /ssd-vol0/logs/lipase2027h1/data/roots.pem -Generated /ssd-vol0/logs/lipase2027h1/data/.env -Generated /ssd-vol0/logs/lipase2027h2/data/roots.pem -Generated /ssd-vol0/logs/lipase2027h2/data/.env +Creating /ssd-vol0/logs/lipase2025h2/data/roots.pem +Creating /ssd-vol0/logs/lipase2025h2/data/.env +Creating /ssd-vol0/logs/lipase2026h1/data/roots.pem +Creating /ssd-vol0/logs/lipase2026h1/data/.env +Creating /ssd-vol0/logs/lipase2026h2/data/roots.pem +Creating /ssd-vol0/logs/lipase2026h2/data/.env +Creating /ssd-vol0/logs/lipase2027h1/data/roots.pem +Creating /ssd-vol0/logs/lipase2027h1/data/.env +Creating /ssd-vol0/logs/lipase2027h2/data/roots.pem +Creating /ssd-vol0/logs/lipase2027h2/data/.env ``` Looking at one of those .env files, I can show the exact commandline I'll be feeding to the @@ -344,14 +350,14 @@ And thus, `gen-nginx` command is born, and listens on port `:8080` for requests: ``` ctlog@ctlog1:/ssd-vol0/enc/tesseract$ tesseract-genconf -c tesseract-staging.yaml gen-nginx -Generated nginx config: /ssd-vol0/logs/lipase2025h2/data/lipase2025h2.mon.ct.ipng.ch.conf -Generated nginx config: /ssd-vol0/logs/lipase2026h1/data/lipase2026h1.mon.ct.ipng.ch.conf -Generated nginx config: /ssd-vol0/logs/lipase2026h2/data/lipase2026h2.mon.ct.ipng.ch.conf -Generated nginx config: /ssd-vol0/logs/lipase2027h1/data/lipase2027h1.mon.ct.ipng.ch.conf -Generated nginx config: /ssd-vol0/logs/lipase2027h2/data/lipase2027h2.mon.ct.ipng.ch.conf +Creating nginx config: /ssd-vol0/logs/lipase2025h2/data/lipase2025h2.mon.ct.ipng.ch.conf +Creating nginx config: /ssd-vol0/logs/lipase2026h1/data/lipase2026h1.mon.ct.ipng.ch.conf +Creating nginx config: /ssd-vol0/logs/lipase2026h2/data/lipase2026h2.mon.ct.ipng.ch.conf +Creating nginx config: /ssd-vol0/logs/lipase2027h1/data/lipase2027h1.mon.ct.ipng.ch.conf +Creating nginx config: /ssd-vol0/logs/lipase2027h2/data/lipase2027h2.mon.ct.ipng.ch.conf ``` -All that's left for me to do is symlink these from `/etc/nginx-sites-enabled/` and the read-path is +All that's left for me to do is symlink these from `/etc/nginx/sites-enabled/` and the read-path is off to the races. With these commands in the `tesseract-genconf` tool, I am hoping that future travelers have an easy time setting up their static log. Please let me know if you'd like to use, or contribute, to the tool. You can find me in the Transparency Dev Slack, in #ct and also #cheese. From 825335cef9df78192f793acd0aebc583a596fe5e Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 25 Aug 2025 10:25:43 +0000 Subject: [PATCH 02/12] Typo fixes --- content/articles/2025-08-24-ctlog-3.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/articles/2025-08-24-ctlog-3.md b/content/articles/2025-08-24-ctlog-3.md index c7514b6..8cba7e5 100644 --- a/content/articles/2025-08-24-ctlog-3.md +++ b/content/articles/2025-08-24-ctlog-3.md @@ -14,7 +14,7 @@ subsequently it issued hundreds of fraudulent SSL certificates, some of which we man-in-the-middle attacks on Iranian Gmail users. Not cool. Google launched a project called **Certificate Transparency**, because it was becoming more common -that the root of trust given to _Certification Authorities_ could no longer be unilateraly trusted. +that the root of trust given to _Certification Authorities_ could no longer be unilaterally trusted. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious [[project](https://certificate.transparency.dev/)] to improve security online by bringing @@ -49,8 +49,8 @@ yet, take a look at [[zrepl](https://zrepl.github.io/)], a one-stop, integrated replication. This tool is incredibly powerful, and can do snapshot management, sourcing / sinking to remote hosts, of course using incremental snapshots as they are native to ZFS. -Once the machine is up, we pass three four enterprise-class storage, in our case 3.84TB Kioxia NVMe -drives, model _KXD51RUE3T84_ which are PCIe 3.1 x4 lanes, and NVMe 1.2.1 specification with a good +Once the machine is up, we pass four enterprise-class storage drives, in our case 3.84TB Kioxia +NVMe, model _KXD51RUE3T84_ which are PCIe 3.1 x4 lanes, and NVMe 1.2.1 specification with a good durability and reasonable (albeit not stellar) read throughput of ~2700MB/s, write throughput of ~800MB/s with 240 kIOPS random read and 21 kIOPS random write. My attention is also drawn to a specific specification point: these drives allow for 1.0 DWPD, which stands for _Drive Writes Per @@ -500,7 +500,7 @@ allow the Static CT logs (regardless of being Sunlight or TesseraCT) to serve ve ## What's Next -I need to spend a little bit of time thinking about rate limites, specifically write-ratelimits. I +I need to spend a little bit of time thinking about rate limits, specifically write-ratelimits. I think I'll use a request limiter in upstream NGINX, to allow for each IP or /24 or /48 subnet to only send a fixed number of requests/sec. I'll probably keep that part private though, as it's a good rule of thumb to never offer information to attackers. From a9e978effb4fc705b8b16f665062587f72af4528 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 25 Aug 2025 10:29:59 +0000 Subject: [PATCH 03/12] A few typo changes --- content/articles/2025-07-26-ctlog-1.md | 2 +- content/articles/2025-08-10-ctlog-2.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/articles/2025-07-26-ctlog-1.md b/content/articles/2025-07-26-ctlog-1.md index cd5c6e1..91c698a 100644 --- a/content/articles/2025-07-26-ctlog-1.md +++ b/content/articles/2025-07-26-ctlog-1.md @@ -14,7 +14,7 @@ subsequently it issued hundreds of fraudulent SSL certificates, some of which we man-in-the-middle attacks on Iranian Gmail users. Not cool. Google launched a project called **Certificate Transparency**, because it was becoming more common -that the root of trust given to _Certification Authorities_ could no longer be unilateraly trusted. +that the root of trust given to _Certification Authorities_ could no longer be unilaterally trusted. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious [[project](https://certificate.transparency.dev/)] to improve security online by bringing diff --git a/content/articles/2025-08-10-ctlog-2.md b/content/articles/2025-08-10-ctlog-2.md index f951d26..48ff2a5 100644 --- a/content/articles/2025-08-10-ctlog-2.md +++ b/content/articles/2025-08-10-ctlog-2.md @@ -14,7 +14,7 @@ subsequently it issued hundreds of fraudulent SSL certificates, some of which we man-in-the-middle attacks on Iranian Gmail users. Not cool. Google launched a project called **Certificate Transparency**, because it was becoming more common -that the root of trust given to _Certification Authorities_ could no longer be unilateraly trusted. +that the root of trust given to _Certification Authorities_ could no longer be unilaterally trusted. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious [[project](https://certificate.transparency.dev/)] to improve security online by bringing @@ -53,11 +53,11 @@ implementations, TesseraCT or Sunlight, he thinks would be a good fit. One thing with me: "The community needs _any_ static log operator, so if Google thinks TesseraCT is ready, by all means use that. The diversity will do us good!". -To find out if one or the other is 'ready' is partly on the software, but importantly also an the +To find out if one or the other is 'ready' is partly on the software, but importantly also on the operator. So I carefully take Sunlight out of its cardboard box, and put it onto the same Dell R630 that I used in my previous tests: two Xeon E5-2640 v4 CPUs for a total of 20 cores and 40 threads, -and 512GB of DDR4 memory. They also sport a SAS controller. In one machine I place 6pcs 1.2TB SAS3 -disks (HPE part number EG1200JEHMC), and in the second machine I place 6pcs of 1.92TB enterprise +and 512GB of DDR4 memory. They also sport a SAS controller. In one machine I place 6 pcs 1.2TB SAS3 +drives (HPE part number EG1200JEHMC), and in the second machine I place 6pcs of 1.92TB enterprise storage (Samsung part number P1633N19). ### Sunlight: setup @@ -70,7 +70,7 @@ tools is easy enough, there are three main tools: 1. ***skylight***: Which serves the read-path. `/checkpoint` and things like `/tile` and `/issuer` are served here in a spec-compliant way. -The YAML configuration file is staight forward, and can define and handle multiple logs in one +The YAML configuration file is straightforward, and can define and handle multiple logs in one instance, which sets it apart from TesseraCT which can only handle one log per instance. There's a `submissionprefix` which `sunlight` will use to accept writes, and a `monitoringprefix` which `skylight` will use for reads. From 619a1dfdf261df6348e49502deccf0f3031236b6 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 25 Aug 2025 13:01:55 +0000 Subject: [PATCH 04/12] A few typo fixes, h/t claude --- content/articles/2021-02-26-history.md | 2 +- content/articles/2021-03-27-coloclue-vpp.md | 2 +- content/articles/2025-08-24-ctlog-3.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/articles/2021-02-26-history.md b/content/articles/2021-02-26-history.md index 93fc4c5..f455170 100644 --- a/content/articles/2021-02-26-history.md +++ b/content/articles/2021-02-26-history.md @@ -8,7 +8,7 @@ Historical context - todo, but notes for now 1. started with stack.nl (when it was still stack.urc.tue.nl), 6bone and watching NASA multicast video in 1997. 2. founded ipng.nl project, first IPv6 in NL that was usable outside of NREN. -3. attacted attention of the first few IPv6 partitipants in Amsterdam, organized the AIAD - AMS-IX IPv6 Awareness Day +3. attracted attention of the first few IPv6 participants in Amsterdam, organized the AIAD - AMS-IX IPv6 Awareness Day 4. launched IPv6 at AMS-IX, first IXP prefix allocated 2001:768:1::/48 > My Brilliant Idea Of The Day -- encode AS number in leetspeak: `::AS01:2859:1`, because who would've thought we would ever run out of 16 bit AS numbers :) 5. IPng rearchitected to SixXS, and became a very large scale deployment of IPv6 tunnelbroker; our main central provisioning system moved around a few times between ISPs (Intouch, Concepts ICT, BIT, IP Man) diff --git a/content/articles/2021-03-27-coloclue-vpp.md b/content/articles/2021-03-27-coloclue-vpp.md index e84885a..6985531 100644 --- a/content/articles/2021-03-27-coloclue-vpp.md +++ b/content/articles/2021-03-27-coloclue-vpp.md @@ -185,7 +185,7 @@ function is_coloclue_beacon() } ``` -Then, I ran the configuration again with one IPv4 beacon set on dcg-1, and still all the bird configs on both IPv4 and IPv6 for all routers parsed correctly, and the generated function on the dcg-1 IPv4 filters file was popupated: +Then, I ran the configuration again with one IPv4 beacon set on dcg-1, and still all the bird configs on both IPv4 and IPv6 for all routers parsed correctly, and the generated function on the dcg-1 IPv4 filters file was populated: ``` function is_coloclue_beacon() { diff --git a/content/articles/2025-08-24-ctlog-3.md b/content/articles/2025-08-24-ctlog-3.md index 8cba7e5..c7b1e39 100644 --- a/content/articles/2025-08-24-ctlog-3.md +++ b/content/articles/2025-08-24-ctlog-3.md @@ -34,7 +34,7 @@ and [[TesseraCT]({{< ref 2025-08-10-ctlog-2 >}})], two open source implementatio protocol. In this final article, I'll share the details on how I created the environment and production instances for four logs that IPng will be providing: Rennet and Lipase are two ingredients to make cheese and will serve as our staging/testing logs. Gouda and Halloumi are two -delicious cheeses that pay hommage to our heritage, Jeroen and I being Dutch and Antonis being +delicious cheeses that pay homage to our heritage, Jeroen and I being Dutch and Antonis being Greek. ## Hardware From 26ae98d9775d1c5cf2430b69c6feb1c9828d7c16 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Tue, 26 Aug 2025 08:25:12 +0000 Subject: [PATCH 05/12] Add start/limit flags to .env, h/t philippe --- content/articles/2025-08-24-ctlog-3.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/articles/2025-08-24-ctlog-3.md b/content/articles/2025-08-24-ctlog-3.md index c7b1e39..12bba46 100644 --- a/content/articles/2025-08-24-ctlog-3.md +++ b/content/articles/2025-08-24-ctlog-3.md @@ -322,7 +322,8 @@ Looking at one of those .env files, I can show the exact commandline I'll be fee ctlog@ctlog1:/ssd-vol0/enc/tesseract$ cat /ssd-vol0/logs/lipase2025h2/data/.env TESSERACT_ARGS="--private_key=/ssd-vol0/enc/tesseract/keys/lipase2025h2.pem --origin=lipase2025h2.log.ct.ipng.ch --storage_dir=/ssd-vol0/logs/lipase2025h2/data - --roots_pem_file=/ssd-vol0/logs/lipase2025h2/data/roots.pem --http_endpoint=[::]:16900" + --roots_pem_file=/ssd-vol0/logs/lipase2025h2/data/roots.pem --http_endpoint=[::]:16900 + --not_after_start=2025-07-01T00:00:00Z --not_after_limit=2026-01-01T00:00:00Z" OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 ``` From a1a98ad3c6ad3a18f8a01e11e53a5f3a75826bed Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Tue, 26 Aug 2025 09:19:41 +0000 Subject: [PATCH 06/12] Erratum: Tesseract/POSIX uses BadgerDB, not MariaDB, h/t alcutter@ --- content/articles/2025-08-10-ctlog-2.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/articles/2025-08-10-ctlog-2.md b/content/articles/2025-08-10-ctlog-2.md index 48ff2a5..4d4eb6a 100644 --- a/content/articles/2025-08-10-ctlog-2.md +++ b/content/articles/2025-08-10-ctlog-2.md @@ -621,12 +621,13 @@ to the task of serving the current write-load (which is about 250/s). * ***S3***: When using the S3 backend, TesseraCT became quite unhappy above 800/s while Sunlight went all the way up to 4'200/s and sent significantly less requests to MinIO (about 4x less), - while showing good telemetry on the use of S3 backends. + while showing good telemetry on the use of S3 backends. In this mode, TesseraCT uses MySQL (in + my case, MariaDB) which was not on the ZFS pool, but on the boot-disk. * ***POSIX***: When using normal filesystem, Sunlight seems to peak at 4'800/s while TesseraCT went all the way to 12'000/s. When doing so, Disk IO was quite similar between the two - solutions, taking into account that TesseraCT runs MariaDB (which my setup did not use ZFS - for), while Sunlight uses sqlite3 on the ZFS pool. + solutions, taking into account that TesseraCT runs BadgerDB, while Sunlight uses sqlite3, + both are using their respective ZFS pool. ***Notable***: Sunlight POSIX and S3 performance is roughly identical (both handle about 5'000/sec), while TesseraCT POSIX performance (12'000/s) is significantly better than its S3 From 8683d570a19d11ef9059406d27cc3e8af838b5ce Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Tue, 26 Aug 2025 09:27:06 +0000 Subject: [PATCH 07/12] Add alias for renamed article --- content/articles/2025-07-26-ctlog-1.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/articles/2025-07-26-ctlog-1.md b/content/articles/2025-07-26-ctlog-1.md index 91c698a..55860b8 100644 --- a/content/articles/2025-07-26-ctlog-1.md +++ b/content/articles/2025-07-26-ctlog-1.md @@ -1,6 +1,8 @@ --- date: "2025-07-26T22:07:23Z" title: 'Certificate Transparency - Part 1 - TesseraCT' +aliases: +- /s/articles/2025/07/26/certificate-transparency-part-1/ --- {{< image width="10em" float="right" src="/assets/ctlog/ctlog-logo-ipng.png" alt="ctlog logo" >}} From 512cfd75dcb7bb4ecd9de19872927d1ad9eabedb Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 8 Sep 2025 22:10:24 +0000 Subject: [PATCH 08/12] Retire halloumi2026h2 --- content/ctlog.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/ctlog.md b/content/ctlog.md index 0afa062..e7a5757 100644 --- a/content/ctlog.md +++ b/content/ctlog.md @@ -57,6 +57,9 @@ Our TesseraCT logs: starting from temporal shared `lipase2025h2`. * A production log called [[Halloumi](https://halloumi2025h2.log.ct.ipng.ch/)], incepted 2025-08-24, starting from temporal shared `halloumi2025h2`. + * Log `halloumi2026h2` incorporated incorrect data into its Merkle Tree at entry 4357956 and + 4552365, due to a [[TesseraCT bug](https://github.com/transparency-dev/tesseract/issues/553)] + and was retired on 2025-09-08, to be replaced by temporal shard `halloumi2026h2a`. ## Operational Details From 1b95e25331a5c5ac3b3292c60edae6716c4b2a60 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 29 Sep 2025 15:19:08 +0000 Subject: [PATCH 09/12] Update content/ctlog.md typo fixes, s/shared/shard/ --- content/ctlog.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ctlog.md b/content/ctlog.md index e7a5757..7945f83 100644 --- a/content/ctlog.md +++ b/content/ctlog.md @@ -54,10 +54,10 @@ successor to Trillian's CTFE. Our TesseraCT logs: * A staging log called [[Lipase](https://lipase2025h2.log.ct.ipng.ch/)], incepted 2025-08-22, - starting from temporal shared `lipase2025h2`. + starting from temporal shard `lipase2025h2`. * A production log called [[Halloumi](https://halloumi2025h2.log.ct.ipng.ch/)], incepted 2025-08-24, - starting from temporal shared `halloumi2025h2`. - * Log `halloumi2026h2` incorporated incorrect data into its Merkle Tree at entry 4357956 and + starting from temporal shard `halloumi2025h2`. + * Shard `halloumi2026h2` incorporated incorrect data into its Merkle Tree at entry 4357956 and 4552365, due to a [[TesseraCT bug](https://github.com/transparency-dev/tesseract/issues/553)] and was retired on 2025-09-08, to be replaced by temporal shard `halloumi2026h2a`. From 603f787fd33b08abcfbd3ec9fbe97434388b95a4 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Wed, 3 Dec 2025 18:12:17 +0100 Subject: [PATCH 10/12] Publish archives --- content/ctlog.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/ctlog.md b/content/ctlog.md index 7945f83..2887a93 100644 --- a/content/ctlog.md +++ b/content/ctlog.md @@ -71,3 +71,13 @@ You can read more details about our infrastructure on: The operators of this infrastructure are **Antonis Chariton**, **Jeroen Massar** and **Pim van Pelt**. \ You can reach us via e-mail at [[](mailto:ct-ops@ipng.ch)]. +## Archived logs + +Logs are archived in the [[c2sp.org/static-ct-api@v1.0.0](https://c2sp.org/static-ct-api@v1.0.0)] format, +although if they were originally served through RFC 6962 APIs, leaves might miss the LeafIndex extension. + +Our archived logs are: + +* halloumi2026h2.log.ct.ipng.ch - [[checkpoint](https://ct.ipng.ch/archive/halloumi2026h2/checkpoint)] - [[log.v3.json](https://ct.ipng.ch/archive/halloumi2026h2/log.v3.json)] - [[data](https://ct.ipng.ch/archive/halloumi2026h2/)] + +We also submit them to [[github.com/geomys/ct-archive](https://github.com/geomys/ct-archive)]. From e99f8262433659cad3a2a3bc76ea4413bbb57068 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Wed, 3 Dec 2025 18:23:41 +0100 Subject: [PATCH 11/12] Make note of the archival timing (2wk after notafterlimit) --- content/ctlog.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/content/ctlog.md b/content/ctlog.md index 2887a93..df6eede 100644 --- a/content/ctlog.md +++ b/content/ctlog.md @@ -61,6 +61,19 @@ Our TesseraCT logs: 4552365, due to a [[TesseraCT bug](https://github.com/transparency-dev/tesseract/issues/553)] and was retired on 2025-09-08, to be replaced by temporal shard `halloumi2026h2a`. +## Archived logs + +Logs are archived in the [[c2sp.org/static-ct-api@v1.0.0](https://c2sp.org/static-ct-api@v1.0.0)] format, +although if they were originally served through RFC 6962 APIs, leaves might miss the LeafIndex extension. +IPng archives its static log shards at least two weeks after the _notafterlimit_, and removes the DNS +entries at least two weeks after archiving. + +Our archived logs are: + +* halloumi2026h2.log.ct.ipng.ch - [[checkpoint](https://ct.ipng.ch/archive/halloumi2026h2/checkpoint)] - [[log.v3.json](https://ct.ipng.ch/archive/halloumi2026h2/log.v3.json)] - [[data](https://ct.ipng.ch/archive/halloumi2026h2/)] + +We also submit them to [[github.com/geomys/ct-archive](https://github.com/geomys/ct-archive)]. + ## Operational Details You can read more details about our infrastructure on: @@ -71,13 +84,3 @@ You can read more details about our infrastructure on: The operators of this infrastructure are **Antonis Chariton**, **Jeroen Massar** and **Pim van Pelt**. \ You can reach us via e-mail at [[](mailto:ct-ops@ipng.ch)]. -## Archived logs - -Logs are archived in the [[c2sp.org/static-ct-api@v1.0.0](https://c2sp.org/static-ct-api@v1.0.0)] format, -although if they were originally served through RFC 6962 APIs, leaves might miss the LeafIndex extension. - -Our archived logs are: - -* halloumi2026h2.log.ct.ipng.ch - [[checkpoint](https://ct.ipng.ch/archive/halloumi2026h2/checkpoint)] - [[log.v3.json](https://ct.ipng.ch/archive/halloumi2026h2/log.v3.json)] - [[data](https://ct.ipng.ch/archive/halloumi2026h2/)] - -We also submit them to [[github.com/geomys/ct-archive](https://github.com/geomys/ct-archive)]. From 1bd4be47a34a952a79b338a313832ecdf65f60f0 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Thu, 1 Jan 2026 11:19:17 +0100 Subject: [PATCH 12/12] Happy New Year, IPng --- content/_index.md | 5 +++-- content/about.md | 6 +++--- content/services.md | 8 ++++++++ hugo.yaml | 4 +--- 4 files changed, 15 insertions(+), 8 deletions(-) diff --git a/content/_index.md b/content/_index.md index dcce2d6..1561dbc 100644 --- a/content/_index.md +++ b/content/_index.md @@ -17,13 +17,14 @@ to be connected to the industry both physically, in terms of software defined ne and software companies, and socially, to the Swiss and European networking community. IPng Networks GmbH provides networking consultancy, hosting, colocation, internet connectivity -options primarily tailored for the Zurich metropolitan area. +options primarily tailored for the Zurich metropolitan area. We are experts in self-hosting, and +on principle only use fully open sourced components to build and run our business. Rather than dazzle you with pictures of clouds, grandiose projections of our "global IP backbone", and other claims that small businesses make to appear larger than they are, we're happy to show what we know, what we own, and how we can help you accomplish your goals if you want to work with us. -### Keywords: SDN, WDM, IP, Network Design and Consultancy, Hosting, and Colocation. +### Keywords: VPP/FD.io, Network Design and Consultancy, (Self-)Hosting, and Colocation. We are proud of our network and the services we operate, because they allow us to provide predictable and reliable performance. We maintain and grow the network judiciously and with the diff --git a/content/about.md b/content/about.md index 30c8077..9af9bf9 100644 --- a/content/about.md +++ b/content/about.md @@ -47,8 +47,8 @@ started his career as a network engineer in the Netherlands, where he worked for Intouch, Freeler, and BIT. He helped raise awareness for IPv6, for example by launching it at AMS-IX back in 2001. He also operated [[SixXS](https://www.sixxs.net/)], a global IPv6 tunnel broker, from 2001 through -to its sunset in 2017. Since 2006, Pim works as a Distinguished SRE at Google +to its sunset in 2017. Since 2006, Pim works as a Distinguished Software Engineer at Google in Zurich, Switzerland. In his free time, he goes [[Geocaching](https://geocaching.com)], -contributes to [[open source](https://github.com/pimvanpelt)] projects, and flies -model helicopters. +contributes to [[open source](https://git.ipng.ch/ipng/)] projects, and occasionally +flies model helicopters. diff --git a/content/services.md b/content/services.md index 537367c..379f0df 100644 --- a/content/services.md +++ b/content/services.md @@ -56,6 +56,14 @@ can help broker a deal that is tailored to your needs. You can read more about how we built our own colocation from scratch in this [[informative post]( {{< ref "2022-02-24-colo" >}})]. +### Self-Hosting + +For IPng it's important to take back a little bit of responsibility for our online presence, away +from centrally hosted services and to privately operated ones. We are experts at self-hosting, with +services such as [[Mastodon](https://ublog.tech)], [[Pixelfed](https://pix.ublog.tech/)], +[[Loops](https://flx.ublog.tech/)], [[PeerTube](https://video.ipng.ch/)], [[Mail]({{< ref +2024-05-17-smtp >}})] and myriad others. + ## Project Design / Execution {{< image width="15em" float="right" src="/assets/pdu19.png" alt="19 inch PDU" >}} diff --git a/hugo.yaml b/hugo.yaml index baf25cb..128f567 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -12,7 +12,7 @@ params: showBlogLatest: false mainSections: ["articles"] showTaxonomyLinks: false - nBlogLatest: 14 # number of blog post om the home page + nBlogLatest: 20 # number of blog post om the home page Paginate: 30 blogLatestHeading: "Latest Dabblings" footer: "Copyright 2021- IPng Networks GmbH, all rights reserved" @@ -20,10 +20,8 @@ params: social: email: "info+www@ipng.ch" mastodon: "@IPngNetworks" - twitter: "IPngNetworks" linkedin: "pimvanpelt" github: "pimvanpelt" - instagram: "IPngNetworks" rss: true taxonomies: