mirror of
https://github.com/H0llyW00dzZ/My-RESTAPIs-Boilerplate.git
synced 2025-02-06 09:44:31 +00:00
90 lines
5.0 KiB
Plaintext
90 lines
5.0 KiB
Plaintext
# IDE specific files
|
|
.vscode
|
|
.idea
|
|
# https://idx.google.com it's free
|
|
.idx
|
|
|
|
k8s-deployment/
|
|
.env
|
|
|
|
# H0llyW00dzZ server boring TLS 1.3 cert
|
|
boring-boring-boring.txt
|
|
boring-cert.pem
|
|
boring-key.pem
|
|
|
|
# H0llyW00dzZ cloudflare acm TLS 1.3 cert
|
|
acm-cloudflare.pem
|
|
acm-cloudflare-priv8.pem
|
|
|
|
# H0llyW00dzZ client boring TLS 1.3 cert
|
|
# Note: This won't work in browser, only in go
|
|
boring-client-cert.pem
|
|
boring-client-key.pem
|
|
|
|
# H0llyW00dzZ CA & RootCA TLS 1.3 certificates
|
|
# The RootCA and CA are different entities. Both the RootCA's private key and the private key in "boring-ca.pem" are bound to hardware security modules (see https://www.digicert.com/what-is-pki for information on PKI private keys).
|
|
# Additionally, RootCA or CA are not compatible with Trust Signed certificates (which are needed for browser compatibility)
|
|
# because they are designed for private authorization purposes and are not self-signed. (If they were self-signed, they wouldn't work when using the TLS Go standard library with InsecureSkipVerify set to false.)
|
|
# List of Current Well-Known Methods that Work:
|
|
# - Cloudflare (see https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/)
|
|
# - Cloudflare ACM (see https://developers.cloudflare.com/ssl/origin-configuration/custom-origin-trust-store/)
|
|
#
|
|
# boring-ca.pem = Subordinate (intermediate) CA + Pools that were made and signed by the RootCA. It's a CA chain, basically.
|
|
# This Subordinate (intermediate) CA, once made and signed by the RootCA, can be used for:
|
|
# - Leaf CA (where the domain will be bound, then this leaf CA will be put in a Cloud Provider such as Heroku)
|
|
# - Client/Server authentication (needed for authentication established over HTTP)
|
|
# - mTLS (mutual TLS)
|
|
# Out of topic (OOT) This Subordinate (intermediate) CA, once made and signed by the RootCA, can be used for:
|
|
# - Secure Software Distribution (Code Signing)
|
|
# - Email Signing and Encryption
|
|
# - Document Signing and Encryption
|
|
# - Database Encryption
|
|
# - Virtual Machine (VM) Encryption
|
|
# - Virtual Private Networks (VPNs): In VPN setups, list certificates can be used to authenticate clients or servers before allowing them to join the VPN.
|
|
# - Peer-to-peer networks: In peer-to-peer networks, where nodes need to communicate directly with each other, list certificates can be used for mutual authentication.
|
|
# - Internet of Things (IoT) devices: In IoT environments, where devices may have limited computational resources, list certificates can provide a lightweight authentication mechanism.
|
|
# - Closed networks or intranets (Currently used for Cloudflare (Frontend) & Heroku (Backend), which works well, allowing any browser or tools like curl to access api-beta.btz.pm): In closed networks or intranets, where the participants are known and controlled,
|
|
# list certificates can be used for authentication instead of relying on a public certificate authority (CA).
|
|
#
|
|
# Note: The explained in list of use cases (VPN,P2P,IoT,Closed Networks) for the Subordinate (intermediate) CA is based on well-known knowledge.
|
|
boring-ca.pem
|
|
# boring-RootCA.pem = The Root CA can be found in:
|
|
# - Creating a private CA with self-signed certificates and then generating Subordinate (intermediate) certificates.
|
|
# - Creating a private CA with certificates signed by a trusted CA (this is what I am personally using) and then generating Subordinate (intermediate) certificates.
|
|
#
|
|
# However, self-signed certificates & certificates signed by a trusted CA are not recommended for testing (even when InsecureSkipVerify is set to true).
|
|
# It's recommended to use a Subordinate (intermediate) CA which has already been made, then test with InsecureSkipVerify set to false (default TLS Config Go standard library).
|
|
#
|
|
# Important: Never test TLS with InsecureSkipVerify set to true (this is a bad practice).
|
|
#
|
|
# Important: When creating a CA (Root CA or Subordinate (intermediate) CA), make sure it is correctly chained. If the chaining is incorrect,
|
|
# regardless of whether it is legitimate or tampered with (non-legitimate, which is considered compromised by an attacker in the middle), it can lead to the CA being untrusted when scanned
|
|
# (see demo at https://decoder.link/sslchecker/api-beta.btz.pm/443).
|
|
boring-RootCA.pem
|
|
|
|
# Google Trust Service (Well-Known)
|
|
# Repo: https://pki.goog/repository/
|
|
gts-ca.pem
|
|
gts-RootCA.pem
|
|
|
|
# Tailwind.css contain input tailwind css for testing purpose.
|
|
tailwind.css
|
|
# Go CSS Generator (not available yet).
|
|
tailwind.go
|
|
|
|
# Cache Compression (gzip)
|
|
#
|
|
# Note: When using the Cache Middleware with the WithCacheControl option set to true and a Storage provider (e.g., Redis or Valkey),
|
|
# the compressed files will be automatically stored in the specified Storage provider and sent to the client (browser).
|
|
# The compressed files are not stored in the server's memory.
|
|
#
|
|
# However, if the WithCacheControl option is set to false, the compressed files will be stored in the server's memory.
|
|
# In this case, it is recommended to implement a storage mechanism that stores the files on disk instead of memory to avoid excessive memory consumption.
|
|
*.gz
|
|
|
|
# GCloud Builds
|
|
gcloud-builds.yaml
|
|
|
|
# Ignore github
|
|
.github
|