sslmate / certspotter Goto Github PK

I think the entire PEM-encoded certificate chain should be fed to the script over stdin. Cert Spotter should ignore broken pipes in case the script closes stdin before reading anything. Question: what if the script forks with stdin still open and never reads?

I can't get the certspotter client to do an -all_time scan. It ends immediately, only checking for newer certs:

$ certspotter -state_dir /opt/certspotter -all_time -verbose

certspotter: https://ct.googleapis.com/pilot: 2016/07/30 01:53:54 Existing log; scanning 0 new entries since previous scan (previous size 24395383, previous root hash = 141b4982f720f248cd8190f46a914643933041e045e27a98700470a2947c7411)
certspotter: https://ct.googleapis.com/pilot: 2016/07/30 01:53:54 final log size = 24395383, final root hash = 141b4982f720f248cd8190f46a914643933041e045e27a98700470a2947c7411
certspotter: https://ct.googleapis.com/aviator: 2016/07/30 01:53:54 Existing log; scanning 0 new entries since previous scan (previous size 23120116, previous root hash = d1f305aba4234e39e26d00657c234f785d3edf370833042c1ab56454cdea7de3)
certspotter: https://ct.googleapis.com/aviator: 2016/07/30 01:53:54 final log size = 23120116, final root hash = d1f305aba4234e39e26d00657c234f785d3edf370833042c1ab56454cdea7de3
certspotter: https://ct1.digicert-ct.com/log: 2016/07/30 01:53:54 Existing log; scanning 0 new entries since previous scan (previous size 442176, previous root hash = fb00226b2e2ad19ed68b84f3d64399ee25dee4228700274117c7024d1f66ecf3)
certspotter: https://ct1.digicert-ct.com/log: 2016/07/30 01:53:54 final log size = 442176, final root hash = fb00226b2e2ad19ed68b84f3d64399ee25dee4228700274117c7024d1f66ecf3
certspotter: https://ct.googleapis.com/rocketeer: 2016/07/30 01:53:55 Existing log; scanning 0 new entries since previous scan (previous size 21952056, previous root hash = 51cf0dd50b08de1125104cbeff458b5f89e95fafcaee1c502cb467e9a0af6de8)
certspotter: https://ct.googleapis.com/rocketeer: 2016/07/30 01:53:55 final log size = 21952056, final root hash = 51cf0dd50b08de1125104cbeff458b5f89e95fafcaee1c502cb467e9a0af6de8
certspotter: https://ct.ws.symantec.com: 2016/07/30 01:53:55 Existing log; scanning 0 new entries since previous scan (previous size 1034913, previous root hash = ebb8f8d4faec771b572fb2607a39db43fbfa44b28155650f1ecf0945ff115505)
certspotter: https://ct.ws.symantec.com: 2016/07/30 01:53:55 final log size = 1034913, final root hash = ebb8f8d4faec771b572fb2607a39db43fbfa44b28155650f1ecf0945ff115505
certspotter: https://ctlog.api.venafi.com: 2016/07/30 01:53:55 Existing log; scanning 0 new entries since previous scan (previous size 53969, previous root hash = 68659773bbcf01f5df14122bfac7d5a80c63ea61ec64de5a603d3e88306a9c2e)
certspotter: https://ctlog.api.venafi.com: 2016/07/30 01:53:55 final log size = 53969, final root hash = 68659773bbcf01f5df14122bfac7d5a80c63ea61ec64de5a603d3e88306a9c2e
certspotter: https://vega.ws.symantec.com: 2016/07/30 01:53:55 Existing log; scanning 0 new entries since previous scan (previous size 3440, previous root hash = ff13a267dd08a64a311b8b813362ead1f23ca3237310fec562f26044abdaad02)
certspotter: https://vega.ws.symantec.com: 2016/07/30 01:53:55 final log size = 3440, final root hash = ff13a267dd08a64a311b8b813362ead1f23ca3237310fec562f26044abdaad02
certspotter: https://ctserver.cnnic.cn: 2016/07/30 01:53:56 Existing log; scanning 0 new entries since previous scan (previous size 1882, previous root hash = 9cdaf17577f64130c99c317817ccae27b118c16a93ca577a4d296be5d20fc0d6)
certspotter: https://ctserver.cnnic.cn: 2016/07/30 01:53:56 final log size = 1882, final root hash = 9cdaf17577f64130c99c317817ccae27b118c16a93ca577a4d296be5d20fc0d6

Got the following error:

/root/go/bin/certspotter: mammoth.ct.comodo.com: 2017/10/30 13:46:42 Existing log; scanning 3453 new entries since previous scan
/root/go/bin/certspotter: mammoth.ct.comodo.com: 2017/10/30 13:46:42 Starting scan...
/root/go/bin/certspotter: mammoth.ct.comodo.com: 2017/10/30 13:46:42 Fetching entries 24702325 to 24703324
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8049ebc]

goroutine 119 [running]:
sync/atomic.AddUint64(0x189d85ec, 0x1, 0x0, 0x1, 0x3)
        /usr/lib/go-1.8/src/sync/atomic/asm_386.s:112 +0xc
software.sslmate.com/src/certspotter.(*Scanner).processerJob(0x189d85c0, 0x1, 0x18a0a000, 0x8297fdc, 0x189f5280)
        /root/go/src/software.sslmate.com/src/certspotter/scanner.go:88 +0xb5
created by software.sslmate.com/src/certspotter.(*Scanner).Scan
        /root/go/src/software.sslmate.com/src/certspotter/scanner.go:297 +0x141

[13:46 root@ssl-proxy ~] > uname -a
Linux ssl-proxy 3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 20:50:41 UTC 2016 i686 athlon i686 GNU/Linux

[13:50 root@ssl-proxy ~] > lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty

[13:50 root@ssl-proxy ~] > go env
GOARCH="386"
GOBIN=""
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GORACE=""
GOROOT="/usr/lib/go-1.8"
GOTOOLDIR="/usr/lib/go-1.8/pkg/tool/linux_386"
GCCGO="gccgo"
GO386=""
CC="gcc"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build357135451=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

Please help!

Trying out the new daemon mode - thanks so much! I may be missing something obvious, or this perhaps is intentional, but it looks like the first 5 minutes are wasted, with no processing happening, or useful output?

For example:

TMPDIR="$(mktemp -d)"
export CERTSPOTTER_CONFIG_DIR=$TMPDIR/certspotter-cfg
export CERTSPOTTER_STATE_DIR=$TMPDIR/certspotter

mkdir $CERTSPOTTER_CONFIG_DIR $CERTSPOTTER_STATE_DIR
echo '.' > $CERTSPOTTER_CONFIG_DIR/watchlist

certspotter -no_save -start_at_end -stdout -verbose

Output:

2023/02/09 02:55:16 fetched 17 logs from "https://loglist.certspotter.org/monitor.json"
2023/02/09 02:55:16 starting task for log c9meiRtMlnigIH1HneayxhzQUV5xGSqMa4AQesF3crU= (https://nessie2024.ct.digicert.com/log/)

[... more logs ...]

2023/02/09 02:55:17 brand new log https://nessie2024.ct.digicert.com/log/ (starting from 19367775)
2023/02/09 02:55:17 saving state in defer for https://nessie2024.ct.digicert.com/log/

[...more logs...]

[nothing happens for 5 minutes]

2023/02/09 03:00:16 downloading entries from https://ct.cloudflare.com/logs/nimbus2023/ in range [409205419, 409345193)

[..more logs...]

[...certificates in stdout...]

Running as a cron job is sub-optimal for several reasons:

1. It's not obvious what the interval between runs should be. A shorter interval allows for quicker notification of certificates, but if it's too short then certspotter will still be running when cron tries to invoke it again.
2. certspotter has to finish processing all logs before it can be run again. This means that if log A takes 1 minute to process, and log B takes 30 minutes to process, log A can be processed no more frequently than once every 30 minutes, which will delay the notification of certificates in that log.
3. Logs often have transient errors. When this happens, a CT monitor should continuously retry and only report the error if it persists for longer than the MMD. As a cron job, we can't do this because it would block the processing of other logs, so instead we immediately report the error (which contributes to error fatigue) and wait until the next run to try processing again. If certspotter were a daemon, we'd have more flexibility to retry and only report errors if they are persistent, not transient.

Most log errors would be suppressed, but we would want to raise an alarm if any of the following conditions arise:

• We haven't been able to successfully fetch an STH from a log for longer than the log's MMD
• A log has a large backlog of unprocessed certificates (the backlog is the difference between the log's latest STH and the current position)

The downside to running as a daemon is that we can't just print message (certificate details, error messages) to stdout/stderr and rely on the cron daemon to email them. So perhaps certspotter should invoke sendmail itself?

When writing a script for the -script option, I noticed that there are many details about the CT and the certificate. I was wondering if there is a variable to identify the matching search therms from the watchlist.

Example: I have multiple search terms in the watchlist. When I get a script call, I would like to know which search term was triggering it to trigger the correct actions in the script (e.g. notify the correct people, ...)

How could this be done? Is there a variable I did not see documented in Issue #11.

These two logs seem to have been disqualified in Chrome at the very end of 2018-02-12:

• WoSign
• StartCom

Should they be removed from certspotter now? Or is there a reason to keep monitoring them?

$ time echo .eff.org | certspotter  -verbose -all_time -watchlist -
certspotter: https://ct.googleapis.com/pilot: 2016/12/14 15:32:43 Existing log; scanning 0 new entries since previous scan (previous size 57152114, previous root hash = 589e0f0f727a5ad50455486294de8f2d7cbea90d449c75fddb19e147c1fbfad7)
certspotter: https://ct.googleapis.com/pilot: 2016/12/14 15:32:43 final log size = 57152114, final root hash = 589e0f0f727a5ad50455486294de8f2d7cbea90d449c75fddb19e147c1fbfad7
certspotter: https://ct.googleapis.com/aviator: 2016/12/14 15:32:44 Existing log; scanning 0 new entries since previous scan (previous size 46466472, previous root hash = 2dc19c651b26f8b1989ab9720b92d7855d53e8e0fc887e5d3656f4b04265f5b0)
certspotter: https://ct.googleapis.com/aviator: 2016/12/14 15:32:44 final log size = 46466472, final root hash = 2dc19c651b26f8b1989ab9720b92d7855d53e8e0fc887e5d3656f4b04265f5b0
certspotter: https://ct1.digicert-ct.com/log: 2016/12/14 15:32:44 Existing log; scanning 0 new entries since previous scan (previous size 733199, previous root hash = f2832e9a3e6e9f57c43d4ddfd2e6471d7d81628ce39aca0e449cf3cf2502056c)
certspotter: https://ct1.digicert-ct.com/log: 2016/12/14 15:32:44 final log size = 733199, final root hash = f2832e9a3e6e9f57c43d4ddfd2e6471d7d81628ce39aca0e449cf3cf2502056c
certspotter: https://ct.googleapis.com/rocketeer: 2016/12/14 15:32:45 Existing log; scanning 0 new entries since previous scan (previous size 56228621, previous root hash = 79e1617a93abcc084b763b6b39c62454df3007d9d6377003f4b17e2a663b75ba)
certspotter: https://ct.googleapis.com/rocketeer: 2016/12/14 15:32:45 final log size = 56228621, final root hash = 79e1617a93abcc084b763b6b39c62454df3007d9d6377003f4b17e2a663b75ba
certspotter: https://ct.ws.symantec.com: 2016/12/14 15:32:46 Existing log; scanning 0 new entries since previous scan (previous size 2082785, previous root hash = e4726fb167d714a1825ee4ba111292dd31684b26ab8ee238d18882b2e992552e)
certspotter: https://ct.ws.symantec.com: 2016/12/14 15:32:46 final log size = 2082785, final root hash = e4726fb167d714a1825ee4ba111292dd31684b26ab8ee238d18882b2e992552e
certspotter: https://ctlog.api.venafi.com: 2016/12/14 15:32:46 Existing log; scanning 0 new entries since previous scan (previous size 77525, previous root hash = 93f2bfd481e1b56c5291acb271780320d5b46f1c4750ec7a9ddced2ce8c0a9ea)
certspotter: https://ctlog.api.venafi.com: 2016/12/14 15:32:46 final log size = 77525, final root hash = 93f2bfd481e1b56c5291acb271780320d5b46f1c4750ec7a9ddced2ce8c0a9ea
certspotter: https://vega.ws.symantec.com: 2016/12/14 15:32:46 Existing log; scanning 0 new entries since previous scan (previous size 74616, previous root hash = 30c0e266b5ddb18d910e699c6c08ce526022c5e60fe2f9ebac814436c948da3d)
certspotter: https://vega.ws.symantec.com: 2016/12/14 15:32:46 final log size = 74616, final root hash = 30c0e266b5ddb18d910e699c6c08ce526022c5e60fe2f9ebac814436c948da3d
certspotter: https://ctserver.cnnic.cn: 2016/12/14 15:32:47 Existing log; scanning 0 new entries since previous scan (previous size 3558, previous root hash = 11629da08a9ec9724f3472e387866e04df6600177abbb2e08b2d690d0b34726a)
certspotter: https://ctserver.cnnic.cn: 2016/12/14 15:32:47 final log size = 3558, final root hash = 11629da08a9ec9724f3472e387866e04df6600177abbb2e08b2d690d0b34726a

real	0m4,346s
user	0m0,080s
sys	0m0,016s

Deleting ~/.certspotter seems to fix this.

Default list of monitor.json at https://loglist.certspotter.org/monitor.json needs to be updated with updated list at https://www.gstatic.com/ct/log_list/v3/log_list.json

Reference: https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md

State will be stored in the value of -state_dir, but the watchlist is still sourced from ~/.certspotter/watchlist:

$ certspotter -state_dir /opt/certspotter

certspotter: /home/ubuntu/.certspotter/watchlist: open /home/ubuntu/.certspotter/watchlist: no such file or directory

Summary

Certspotter is started via cron job but the job never comes to an end. When cron tries to start the next job as scheduled this fails because another instance of certspotter is already running and the lock file prevents the start of another instance.

When the running process is stopped (kill PID) and the lock file has been removed the problem reoccurs after the next time certspotter was started. So a process is started and cannot complete next process is prevented from starting.

Environment

• OS: Debian GNU/Linux 10 (buster)
• Kernel: 4.19.0-5-amd64 (uname -r)
• Go: go1.11.6 linux/amd64
• Certspotter: Latest version from github

Current status

In this section I try to provide complete information about the current process status.

Crontab entry

42 7 * * * /home/tronde/go/bin/certspotter

Related processes

tronde@host:~$ ps -fp 20273 -p 20274 -p 20275
UID        PID  PPID  C STIME TTY          TIME CMD
root     20273   691  0 Oct06 ?        00:00:00 /usr/sbin/CRON -f
tronde 20274 20273  0 Oct06 ?        00:00:00 /bin/sh -c /home/tronde/go/bin/certspotter
tronde 20275 20274  8 Oct06 ?        02:03:58 /home/tronde/go/bin/certspotter
tronde@host:~$

Open files

tronde@host:~$ sudo lsof -p 20275
COMMAND     PID      USER   FD      TYPE   DEVICE SIZE/OFF      NODE NAME
certspott 20275 tronde  cwd       DIR      9,2     4096  20709378 /home/tronde
certspott 20275 tronde  rtd       DIR      9,2     4096         2 /
certspott 20275 tronde  txt       REG      9,2  7173364  57409601 /home/tronde/go/bin/certspotter
certspott 20275 tronde  mem       REG      9,2  1824496 117712893 /usr/lib/x86_64-linux-gnu/libc-2.28.so
certspott 20275 tronde  mem       REG      9,2   146968 117712993 /usr/lib/x86_64-linux-gnu/libpthread-2.28.so
certspott 20275 tronde  mem       REG      9,2   165632 117712835 /usr/lib/x86_64-linux-gnu/ld-2.28.so
certspott 20275 tronde    0r     FIFO     0,12      0t0  32416847 pipe
certspott 20275 tronde    1u      REG      9,2        0  57409560 /tmp/#57409560 (deleted)
certspott 20275 tronde    2u      REG      9,2        0  57409560 /tmp/#57409560 (deleted)
certspott 20275 tronde    3r      REG      9,2       16  20709927 /home/tronde/.certspotter/watchlist
certspott 20275 tronde    4u  a_inode     0,13        0      9331 [eventpoll]
certspott 20275 tronde    5u     IPv6 33299581      0t0       TCP host:36266->fra16s20-in-x0a.1e100.net:https (ESTABLISHED)
tronde@host:~$

Strace of PID

sudo strace -p 20275
strace: Process 20275 attached
futex(0x919aa0, FUTEX_WAIT_PRIVATE, 0, NULL
^Cstrace: Process 20275 detached
 <detached ...>

Conclusion

Strace was attached to the PID for round about 1 Minute. It seems that the process got stuck in futex for any reason and therefor cannot complete.

My Request

I would like to ask you if you could assist in troubleshooting this issue to find out if this is a bug or just a configuration issue on my machine. I did not have this kind of issue running Ubuntu 18.04 as OS. I see this behavior the first time since I started certspotter on Buster.

If you need any additional information please don't hesitate to ask. I'll do my best helping to solve this issue.

./go/bin/certspotter: Error loading log list: Get https://loglist.certspotter.org/monitor.json: dial tcp 54.236.181.46:443: i/o timeout

certspotter should have a sub-command to submit a certificate chain to logs. It should store the SCTs in the state directory and demand inclusion proofs after the MMD has elapsed.

Open questions:

• How should certspotter decide which logs to submit to?
• Should certspotter attempt to fix incomplete chains?

I'm running certspotter using the script argument. I see occasional errors pop up:

certspotter: ct.googleapis.com/pilot: 2018/09/01 13:33:44 Failed to execute script: ./log_lines.sh: fork/exec ./log_lines.sh: invalid argument

My script is extremely simple, so I think this error is from the $DNS_NAMES argument and not something within my script, but I could be wrong.

usage

certspotter -watchlist ./.certspotter/watchlist.txt -no_save -state_dir ./.certspotter -script ./log_lines.sh

log_lines.sh

#!/usr/bin/env bash

FILE_PREFIX="dns_names"

IFS=',' read -ra ADDR <<< "$DNS_NAMES"
FILE_ENDING=`date +%Y-%m-%d:%H`
for i in "${ADDR[@]}"; do
    echo "$i" >> "${FILE_PREFIX}_${FILE_ENDING}.txt"
done

watchlist.txt

.

For example, in the certbot state directory (inspired by https://mas.to/@zekjur/111273573539477069)

I'm seeing many warnings in the log such as this:

2021/10/12 12:02:09 https://yeti2022-2.ct.digicert.com/log/: Unable to verify consistency of STH 3 (/home/sa.certspotter/.certspotter/logs/BZwB0yDgB4QTlYBJjRF8kDJmr69yULWvO0akPhGEDUo/unverified_sths/3-yD2lvdIhe0VuTmA0lq3io1QpC0Q8ocb90DMs7vhH5kA.json) (if this error persists, it should be construed as misbehavior by the log): Error fetching consistency proof: GET https://yeti2022-2.ct.digicert.com/log/ct/v1/get-sth-consistency?first=0&second=3: 400 BAD REQUEST ()

I suspect it is due to this problem in DigiCert's Yeti2022 log:
https://groups.google.com/a/chromium.org/g/ct-policy/c/hxNohyZncfQ

Is there anything we can do to mitigate this via configuration, or does there need to be an update to certspotter?

The Go code for Certificate Transparency has moved to a separate repo at https://github.com/google/certificate-transparency-go from https://github.com/google/certificate-transparency/tree/master/go

Accordingly, same need to be updated at

https://github.com/SSLMate/certspotter/tree/master/ct

I've installed and configured certspotter as per the instructions. I created a watchlist at ~/.certspotter/watchlist and included a list of 14 domains. When I run certspotter it gives no output to stdin. When I run it with verbose flag I just see it fetching some logs and thats it.

Any ideas?

It should be possible for users to see the current state of monitoring - e.g. which logs are being monitored, how recently they were contacted, what the backlog is

Maybe this could be provided by an optional HTTP server?

I've been running Certspotter for about two weeks and it has found only a handful of certs for the watched domain that actually has close to 100 of them. I'm not sure if this is related, but I see that over 800 of the following messages have been generated:

2023/10/04 10:05:33 error downloading entries from https://sabre2025h2.ct.sectigo.com/: GET https://sabre2025h2.ct.sectigo.com/ct/v1/get-entries?start=20217&end=21216: 400 Bad Request (Bad Request
need tree size: 20218 to get leaves but only got: 20217

The URLs are all related to Sectigo/Comodo:

https://mammoth2024h1.ct.sectigo.com/
https://mammoth2024h2.ct.sectigo.com/
https://mammoth2025h1.ct.sectigo.com/
https://mammoth2025h2.ct.sectigo.com/
https://sabre2024h1.ct.sectigo.com/
https://sabre2024h2.ct.sectigo.com/
https://sabre2025h1.ct.sectigo.com/
https://sabre2025h2.ct.sectigo.com/
https://sabre.ct.comodo.com/

I also see about 100 of these messages, but it doesn't sound like it should be a concern:

certspotter has been unable to download entries from https://ct.googleapis.com/logs/argon2023/ in a timely manner. Consequentially, certspotter may be slow to notify you about certificates in this log.

The URLs in these messages are:

https://ct.cloudflare.com/logs/nimbus2023/
https://ct.cloudflare.com/logs/nimbus2024/
https://ct.googleapis.com/logs/argon2023/
https://ct.googleapis.com/logs/eu1/xenon2024/
https://ct.googleapis.com/logs/us1/argon2024/
https://ct.googleapis.com/logs/xenon2023/
https://oak.ct.letsencrypt.org/2023/
https://oak.ct.letsencrypt.org/2024h1/
https://sabre.ct.comodo.com/
https://yeti2024.ct.digicert.com/log/

Trying to install certspotter on Ubuntu 15.10 with go 1.5.1 and getting:

go get software.sslmate.com/src/certspotter/cmd/certspotter
software.sslmate.com/src/certspotter
.go/src/software.sslmate.com/src/certspotter/asn1time.go:245: undefined: asn1.TagUTCTime
.go/src/software.sslmate.com/src/certspotter/asn1time.go:247: undefined: asn1.TagGeneralizedTime

I'm sure I'm doing something dumb, any ideas?

For a new user it's hard to understand if certspotter is working correctly.
It would be useful if it logs:

• How much domains it started to monitor (from watchlist). maybe some other stat periodically too such as how much logs it sees.
• Test notification/emailing functionality. This could be on signal (like SIGUSR2) or command line option to always email on service start (so we can detect it's restarted and ensure everything is still OK).

Additionally:

• Maybe suggest special domain (or mode?) to see if monitoring and notification work at all?

Also it's hard to understand purpose of -no_save option, why we may need it?

Purpose of submitct is unexplained, where it submit certs and what for?

Thanks,

With a large watchlist, certificates with hundreds of SAN entries and wildcards on both sides, it's difficult to know which SAN triggered the identification of the cert. Would be helpful if the information written to stdout included the matching domain.

(great tool by the way, mad props and all that)

Documentation/README should explain:

• You can't compare certificate fingerprints because precertificates have a different fingerprint.
• You don't want to compare serial numbers because malicious CAs could reuse the serial number.
• Ideally you compare the TBS hash, but there are zero tools for computing this.
• So comparing the public key fingerprint is the best bet.

To avoid unnecessary noise, it would be nice if there were options:

• not to report a certificate that has been already reported in some different log
• not to report a certificate sharing public key with an already reported certificate (targeted mostly for renewals without rekeying)

Thanks for this great peace of software!

I'd like to see the results such as the total number of certificates fetched, but all of the "Fetching certificate ##### of #####" messages that appear when using the -verbose flag are too chatty. With regular verbosity, certspotter obviously does not display anything unless there's a watchlisted certificate found, so that no output is generated and nothing is e-mailed to the user. Can we have a level in between silence and firehose?

Hi, this isn't an issue, but because I didn't immediately find something I naively started running this until I questioned me again how long it'll take while it had fetched about one TiB of data.

I found some papers. These indicate that we can expect an estimated size of roughly 50 TiB as of now (16 TiB until 2018 + 44 GiB/day[1]). This means it'll take 6 days with constant download of 100 MiB/s (which also requires sufficient CPU power). If you have more precise information or think I've written garbage let me know.

[1] https://www.inforsec.org/wp/wp-content/uploads/2020/04/CCS2019-Li.pdf

Cert Spotter should catch name constrained intermediate CAs that are valid for an identifier on the watchlist.

The default monitor.json file contains a DigiCert Yeti2022 Log #2 entry. This CT log currently returns HTTP 400 Bad Request errors, which are logged by certspotter like this:

2021/08/17 13:00:02 https://yeti2022-2.ct.digicert.com/log/: Unable to verify consistency of STH 3 (/var/local/certspotter/.certspotter/logs/BZwB0yDgB4QTlYBJjRF8kDJmr69yULWvO0akPhGEDUo/unverified_sths/3-7q2OCBgybLpAKtVWBbK5Mq2x9sx8wkkLfwFWm87FOzI.json) (if this error persists, it should be construed as misbehavior by the log): Error fetching consistency proof: GET https://yeti2022-2.ct.digicert.com/log/ct/v1/get-sth-consistency?first=0&second=3: 400 BAD REQUEST ()

We are seeing these errors since around two weeks. This CT log is currently not present in Google's log_list.json. I am not sure what the best course of action is, but it might be a good idea to omit this log from the monitor.json file until the log can be used with Certspotter.

It would copy the certificate into the state directory, so you're not alerted when the certificate later shows up in a log.

This command could be invoked by a certbot deploy hook.

Hi guys,

I am totally new to go.

Once I ran

go get software.sslmate.com/src/certspotter/cmd/certspotter

It installs the package in my go path folder under src.

My question is how do I get this thing to run. Running certspotter as a command says it cannot be found . I seen you can pass flags to it and from the cronjob you just run certspotter. I am unsure if I am doing something else wrong or not.

Any help would be much appreciated

detect if a certificate is issued for a domain which resembles a monitored domain.

Messages are missing a Message-ID header here

Could consider adding one?

I think, somethine like

Message-ID: <$sha_of_cert@certspotter>

would be sufficient (spec)

When used with -logs option to update the list of known and trusted CT logs using the log_list.json downloaded from Known Logs list, there are few issues:

• even disqualified logs (those with disqualified_at property) are scanned
• some logs like mammoth.ct.comodo.com return 404 errors due to double slash in the URL: https://mammoth.ct.comodo.com//ct/v1/get-sth
• when a new log is added, it's scanned for entries for all entries which takes a very long time

To workaround first two issues, I've created a small Python script. To workaround the third issue, it's necessary to delete the state files so "first run" is forced.

The plumbing is there, but it needs to be wired up with the watchlist.

certspotter should only notify once for a certificate/precertificate pair.

The best way to implement this is probably to use the TBS fingerprint in the filename in the certs directory instead of the (pre)certificate fingerprint.

Hi

I have started Certspotter and asked it to download from the beginning. It looks like this will take a few hundred years to traverse through. /s

Is there any way to save the progress it has achieved fx. every 1 minute, so in case of panic or I want to reboot, it can continue from that point (with the chance of needing to parse already parsed data)?

So users can be sure that they receive notifications

Possible ideas:

• Command line option
• Optional HTTP server with buttons to fire test notifications

certspotter: ct2.digicert-ct.com/log: 2020/09/17 16:39:05 Error retrieving STH from log: GET https://ct2.digicert-ct.com/log/ct/v1/get-sth: 404 Not Found (not found)

The Rocketeer log is distributed and is frequently unable to return a consistency proof. certspotter should only raise an error if this happens on several subsequent certspotter runs.

Allow user to specify the date we use for checking the expiration, so if they care about certs that were valid at any point in the last 30 days, they can specify that.

Since Monday around 16:00 CET, my Cert Spotter installation has been outputting this on every run:

2021/11/08 16:00:04 https://ct.trustasia.com/log2022/: Error retrieving STH from log: GET https://ct.trustasia.com/log2022/ct/v1/get-sth: 429 Too Many Requests (<html>
<head><title>429 Too Many Requests</title></head>
<body>
<center><h1>429 Too Many Requests</h1></center>
<hr><center>openresty</center>
</body>
</html>
)
2021/11/08 16:00:04 https://ct.trustasia.com/log2023/: Error retrieving STH from log: GET https://ct.trustasia.com/log2023/ct/v1/get-sth: 429 Too Many Requests (<html>
<head><title>429 Too Many Requests</title></head>
<body>
<center><h1>429 Too Many Requests</h1></center>
<hr><center>openresty</center>
</body>
</html>
)

I know that Cert Spotter downloads a list of CT logs to check from certspotter.org before every run, so I guess that something in that list was recently changed. Is this expected behaviour and is TrustAsia's WAF a bit trigger happy or is Cert Spotter incorrectly sending lots of meaningless requests for the empty 2022/2023 TrustAsia logs?

certspotter: ctlog-gen2.api.venafi.com: 2020/09/17 16:38:59 Error retrieving STH from log: GET https://ctlog-gen2.api.venafi.com/ct/v1/get-sth: Parsing response JSON failed: invalid character '<' looking for beginning of value

It's possible to obtain significantly higher throughput by downloading entries in parallel. There are several challenges with this approach, however:

1. We don't know how many entries a log will return, so it's hard to know what the optimal job size is.
2. We'll need to gracefully handle rate limiting.
3. It's much easier to update the Collapsed Merkle Tree serially. I see a few ways to handle this:
   1. We could force the entries to be processed in serial by using a buffered channel of buffered channels. However, I think it will be difficult to reason about buffers.
   2. We could split up jobs on subtree boundaries, making it easy to merge the Collapsed Merkle Trees of all the jobs at the end.
   3. We could devise a sparse Collapsed Merkle Tree data structure which allows nodes to be appended in any order.

Since tonight I'm getting the following error message. My new certificates (LE) are still being detected.

/root/go/bin/certspotter: ctserver.cnnic.cn: 2017/11/20 12:03:04 Error retrieving STH from log: Get https://ctserver.cnnic.cn/ct/v1/get-sth: read tcp 172.16.3.35:42770->218.241.105.21:443: read: connection reset by peer

Opening https://ctserver.cnnic.cn/ct/v1/get-sth gives a SEC_ERROR_UNKNOWN_ISSUER.

Linux icinga2 4.4.0-97-generic #120~14.04.1-Ubuntu SMP Wed Sep 20 15:53:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

GOARCH="amd64"                                                                                                                                                                                                                               
GOBIN=""                                                                                                                                                                                                                                     
GOEXE=""                                                                                                                                                                                                                                     
GOHOSTARCH="amd64"                                                                                                                                                                                                                           
GOHOSTOS="linux"                                                                                                                                                                                                                             
GOOS="linux"                                                                                                                                                                                                                                 
GOPATH="/root/go"                                                                                                                                                                                                                            
GORACE=""                                                                                                                                                                                                                                    
GOROOT="/usr/lib/go-1.9"                                                                                                                                                                                                                     
GOTOOLDIR="/usr/lib/go-1.9/pkg/tool/linux_amd64"                                                                                                                                                                                             
GCCGO="gccgo"                                                                                                                                                                                                                                
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build673615947=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

Hi, I know this isn't exactly certstotter's problem, but I failed to find better place where to ask.

At 12. 02. 21 7:06 CET I've started receiving errors:

/usr/bin/certspotter: ct1.digicert-ct.com/log: 2021/02/12 06:36:15 Problem fetching entries 23910613 to 23910769 from log: GET https://ct1.digicert-ct.com/log/ct/v1/get-entries?start=23910613&end=23910769: Reading response failed: unexpected EOF

I've discovered that by lowering second argument to 23910630 of URL https://ct1.digicert-ct.com/log/ct/v1/get-entries?start=23910613&end=23910630 is almost every time to download valid json.

How to recover from this problem?

Thanks Jan

As you might remember, in Debian we ship with a certspotter-script that run-parts a directory with scripts. I'd like to offer the equivalent kind of functionality that -email provides, but without users having to disable other scripts, or to have to resort to override the systemd unit to add -email.

I've been gearing towards shipping an example shell script hook, to be placed under /etc/certspotter/hooks.d, with something like:

#!/bin/sh
TO=$(cat /etc/certspotter/email-notify)

( cat <<EOF
To: $TO
Subject: [certspotter] ${SUMMARY}
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Mailer: certspotter

EOF
cat ${TEXT_FILENAME} ) | /usr/sbin/sendmail -i -- $TO

This is based off discoveredcert.go and seems to be able replicate its functionality. (Error handling to be added, as well as handling for a non-existent $TO etc. X-Mailer to be reconsidered).

1. How do you feel about that? Risks, issues or other thoughts that you have? Any other alternatives that you can think of?
2. For EVENT=error (staleSTHEvent, backlogEvent, stateLogListEvent) as well as EVENT=malformed_cert (malformedLogEntry) events, it seems like there is no way for the script to access Text(). Do you think we could find a way for this to find its way on the filesystem as well, so that it could be cat'ed into the output as well? It seems like a useful thing to be storing for further inspection anyway, no?
3. This is more minor but I couldn't help to notice the duplication between $SUMMARY and EmailSubject() with very subtle differences (capitalization). Perhaps that's something that could be DRY'ed?

Thanks again for all of your efforts!