dan
/
certifix
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

expand the insecurities section

This commit is contained in:
Daniel Barlow 2024-10-04 23:27:41 +01:00
parent b1e869e125
commit e0e0e0f7cc
1 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
README.md
View File

@ -96,25 +96,27 @@ curl --cacert certs/ca.crt -v -H 'content-type: application/x-pem-file' --data
## Reasons this is not secure ## Reasons this is not secure
* the CA key is readable by and present in the memory of the process * the CA key is readable by and present in the memory of the process
that reads and parses network requests. Bearing in mind the the whole that reads and parses network requests. Bearing in mind the the
point is to automate signing we can only do so much about this, but at whole point is to automate signing we can only do so much about
least we could move the actual signing to a separate process which is this, but at least we could move the actual signing to a separate
only invoked once an acceptable request has been received. process which is only invoked once an acceptable request has been
received.
* there is no intermediate key - the requests are signed directly by the root CA * on that note, in the setup that this README describes there is no
intermediate key - the requests are signed directly by the root
CA. For a robust setup you might consider ignoring my instructions
for generating a self-signed root cert, and instead create a CA
signed by an existing (offline?) root CA
* I haven't checked that the protocols or the ciphers are restricted * I haven't checked that the protocols or the ciphers are restricted
to modern and sensible defaults to modern and sensible defaults
* doesn't set 4.2.1.6. Subject Alternative Name * doesn't call SSL shutdown at the end of the response, so you may get
"unexpected EOF" errors
* doesn't set Key Usage extension (https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3) * it has _not_ been reviewed by anyone who knows about TLS best
practices. If you are that person, please look at the new-crt
* probably has wrong basicConstraints in CA cert function in [main.fnl](main.fnl) and let me know :-)
* doesn't call SSL shutdown at the end of the response
* likewise other TLS best practices
## Background ## Background
@ -122,4 +124,3 @@ only invoked once an acceptable request has been received.
* [RFC 5967 - spec for a CSR](https://datatracker.ietf.org/doc/html/rfc5967) * [RFC 5967 - spec for a CSR](https://datatracker.ietf.org/doc/html/rfc5967)
* [A gentle introduction to ASN1. and DER](https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/) * [A gentle introduction to ASN1. and DER](https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/)
openssl req -newkey rsa:2048 -addext "subjectAltName = DNS:loaclhost.lan,DNS:localhost,DNS:loaclhost.telent.net" -nodes -keyout private/server.key --out certs/server.csr