servercert
cert-gen
servercert | cert-gen | |
---|---|---|
4 | 1 | |
124 | 85 | |
3.3% | - | |
4.7 | 0.0 | |
1 day ago | over 1 year ago | |
CSS | Shell | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
servercert
-
Does my site need HTTPS?
This is permitted: https://github.com/cabforum/servercert/blob/main/docs/BR.md#...
But it hasn't really caught on; a lot of registrars don't seem to want the complexity of being (or integrating with) a CA, and vice versa.
-
Let's Encrypt: Issue with TLS-ALPN-01 Validation Method
It is unfortunate. It's required: https://github.com/cabforum/servercert/blob/main/docs/BR.md#...
-
MarkMonitor left 60k domains for the taking
No, they don't have to MitM the CA's domain validation request. While they have brief control over the website, they use domain validation method 3.2.2.4.18 (Agreed-Upon Change to Website v2)[1] or 3.2.2.4.19 (Agreed-Upon Change to Website - ACME)[2] to legitimately complete domain validation by making a change to the website.
[1] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd...
-
A safer default for navigation: HTTPS
The article you linked to is kind of confused and I'm not sure I blame them. This stuff is really complex!
According to the proposal[0], leaf certificates are prohibited from being signed with a validity window of more than 397 days by a CA/B[1] compliant Certificate authority. This is very VERY different from the cert not being valid. It means that a CA could absolutely make you a certificate that violated these rules. If a CA signed a certificate with a longer window, they would risk having their root CA removed from the CA/B trust store which would make their root certificate pretty much worthless.
To validate this, you can look at the CA certificates that Google has[2] that are set to expire in 2036 (scroll down to "Download CA certificates" and expand the "Root CAs" section) several of which have been issued since that CA/B governance change.
As of right now, as far as I know, Chrome will continue to trust certificates that are signed with a larger window. I've not heard anything about browsers enforcing validity windows or anything like that, but would be delighted to find out the ways that I'm wrong if you can point me to a link.
Further, your home made root certificate will almost certainly not be accepted by CA/B into their trust store (and it sounds like you wouldn't want that) which means you're not bound by their governance. Feel free to issue yourself a certificate that lasts 1000 years and certifies that you're made out of marshmallows or whatever you want. As long as you install the public part of the CA into your devices it'll work great and your phone/laptop/whatever will be 100% sure you're made out of puffed sugar.
I guess I have to disclose that I'm an xoogler who worked on certificate issuance infrastructure and that this is my opinion, that my opinons are bad and I should feel bad :zoidberg:.
[0] https://github.com/cabforum/servercert/pull/138/commits/2b06...
cert-gen
-
A safer default for navigation: HTTPS
> I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN
There almost is! Instead of self signed certificates, use a certificate authority, and install that on the LAN's machines. https://github.com/devilbox/cert-gen
You can use macOS Server or Active Directory to push out the Certificate as trusted.
It's not perfect, but it's close enough for a LAN.
What are some alternatives?
acme-dns - Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.
devcert - Local HTTPS development made easy
devcert-cli - A CLI wrapper for devcert, to manage development SSL/TLS certificates and domains