storj/docs/testplan/linksharing-tls-support.md

Linksharing TLS Support Testplan

 

Background

This testplan is going to cover our secure custom domain support for Linksharing. It will go over the linksharing secure custom domain support blueprint - Paid Tier TLS

 

 

Test Scenario	Test Case	Description	Comments
General	Pro Account Only	Only pro accounts should be able to use Linksharing TLS
	HTTPS Support	Storj linksharing Service should support HTTPS for custom domains
	Host TLS certificates	Linksharing server should host TLS certificates generated by Storj on behalf of our customers (CertMagic: storage backend for storing certificates)
	Certificate Generation	Storj should generate certificates on behalf of users if users have a way to prove ownership of domain to generate said certificate
	Custom Domain URL	Linksharing URLs generated w/ custom domain should also have an additional URL that contains said custom domain	this should be automated as its one of the requirements of the customers; they want/need to have a custom domain that is secured with TLS for their content
	BYO Certificate	(In the future) customers should be able to bring their own certificate rather than rely on our generated certificate, so they should be allowed to upload their said certificate	OUT OF SCOPE
	uplink CLI share request	Customer should be able to make a share request with uplink CLI and be able to update their DNS info w/ output from uplink cli
	Share Access 1	When a share is accessed, linksharing should load the certificate matching the SNI and should attempt to connect said hostname at the start of the handshake
	Share Access 2	Once trying to connect to hostname, linksharing should check for certificate in the cache first and then if it is not there it will check the store
	Valid/Invalid Handshake	If the certificate doesn't exist in the store and the CNAME is valid, then there should be a request for a certificate store domain-lock else this is an invalid handshake and handshake fails/request is dropped
	Successful domain-lock	If the domain-lock succeeds, then the certificate should be requested and the certificate validation process should run afterwards with the new certificate being added to the store
	Multiple Request on domain-lock	When requesting a certificate, additional requests made to the instance holding the lock can be held while the certificate is issued
Migration Impact	Valid Certificate Return	After the migration, existing customers migrated to TLS custom domains should receive a valid cert whenever there is an https request for custom domains
	Warning For HTTPS Support	After TLS custom domain migration, if a customer uses https only mode enabled there should be no warning stating that the site doesn't support HTTPS
	Opt-in TLS Custom Domains	Customers should be allowed to opt-in to TLS custom domains during initial rollouts (to work out potential issues) and should not be enabled by default	this eliminates edge-case described by Paul (if a customer uses a proxy service to use https and expect the self-signed cert serving a valid cert instead could cause an outage) in his research on how existing customers would be impacted when migrated to custom TLS domains
Certificates	Storing	Certificates should only be stored in one private Storj controlled DCS bucket and said bucket should share certificates and other TLS resources needed for the challenges between all linksharing instances
	On-access Renewal	If a certificate expires in less than 30 days and it is accessed, it should then be renewed & if it doesn't expire in less than 30 days it should not be renewed on access
	Expired Certificate	If a certificate expires before it is accessed or after is it accessed for a set time (30 days), then it should be reissued on next access since it will be in process for garbage collection