Outdated example data for breaking change

[d-Rickyy-b]

In the commit 96fcfc0 / PR #56 you removed the 'chain' and the 'as_der' fields from the data. This is quite a breaking change that also hasn't been updated in the README file yet!

certstream-server/README.md

Lines 118 to 161 in 26dff90

	"chain": [
	{
	"subject": {
	"aggregated": "/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3",
	"C": "US",
	"ST": null,
	"L": null,
	"O": "Let's Encrypt",
	"OU": null,
	"CN": "Let's Encrypt Authority X3"
	},
	"extensions": {
	"basicConstraints": "CA:TRUE, pathlen:0",
	"keyUsage": "Digital Signature, Certificate Sign, CRL Sign",
	"authorityInfoAccess": "OCSP - URI:http://isrg.trustid.ocsp.identrust.com\nCA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c\n",
	"authorityKeyIdentifier": "keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10\n",
	"certificatePolicies": "Policy: 2.23.140.1.2.1\nPolicy: 1.3.6.1.4.1.44947.1.1.1\n CPS: http://cps.root-x1.letsencrypt.org\n",
	"crlDistributionPoints": "\nFull Name:\n URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl\n",
	"subjectKeyIdentifier": "A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1"
	},
	"not_before": 1458232846.0,
	"not_after": 1615999246.0,
	"as_der": "::BASE64_DER_CERT::"
	},
	{
	"subject": {
	"aggregated": "/O=Digital Signature Trust Co./CN=DST Root CA X3",
	"C": null,
	"ST": null,
	"L": null,
	"O": "Digital Signature Trust Co.",
	"OU": null,
	"CN": "DST Root CA X3"
	},
	"extensions": {
	"basicConstraints": "CA:TRUE",
	"keyUsage": "Certificate Sign, CRL Sign",
	"subjectKeyIdentifier": "C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10"
	},
	"not_before": 970348339.0,
	"not_after": 1633010475.0,
	"as_der": "::BASE64_DER_CERT::"
	}
	],

Nor have the "subprojects" such as the python module gotten an updated README:
https://github.com/CaliDog/certstream-python#example-data-structure

Also the certstream website does not show this fact immediately: https://certstream.calidog.io/ (under "Certificate Update").
Would you mind fix these examples? Especially important for newcomers!

---

PS: I noticed this only because my application suddenly stored NULL values for the "as_der" and some chain data in the database. As kind of suggestion: It would be lovely to have some sort of API versioning so that applications don't just break from one day to another because API behaviour changed.

[Fitblip]

Hey @d-Rickyy-b, apologies for the oversight! I'll work to get them changed next time I'm working on this.

It would be lovely to have some sort of API versioning so that applications don't just break from one day to another because API behaviour changed.

Yeah actually looking at it it seems as though my github tags have been lost, but we did have things versioned well IIRC :(. I guess my recent history rewrite to reduce the stored files size wiped tags as part of it. At that point the idea is mostly just sticking to a version you're aware of instead of just running master constantly.

As an alternative if you want to grab specific version commits (I'll go back and re-tag when I go fix the other stuff) you can use https://github.com/CaliDog/certstream-server/blame/master/mix.exs and click the "go back in history" icon to find the version you were using previously.

Sorry for the breakage 😅, if you have other ideas about how to manage versions for a project like this other than git tags/releases I'm happy to consider them!

[Fitblip]

Ugh yeah all my tags are gone :(. The metadata seems to still be there in Github so I wonder if I restore the tags it'll restore my releases as well? 🤔

https://github.com/CaliDog/certstream-server/releases/tag/1.4.0
https://github.com/CaliDog/certstream-server/releases/tag/1.5.1

[d-Rickyy-b]

Sorry to hear that. But great that you were able to narrow down the issue quite fast.

if you have other ideas about how to manage versions for a project like this other than git tags/releases I'm happy to consider them!

I was rather talking about your hosted version of certstream on certstream.calidog.io.

Maybe host multiple websocket listeners on different endpoints - such as /api/v1/ and /api/v2/. Of course these need different handling of the data which also means processing overhead. I am no professional web API dev, so maybe you can come up with better ideas. That's just what I saw other applications using for versioning their API.

Little bit of OT: Thanks for building this tool btw. I am currently in the making of (yet another) certificate monitoring tool based on top of certstream.