This small article is a draft which aims to describe the various steps for deploying an HTTPS application from a windows machine along with providing general knowledge regarding the overall concepts.
As a small disclaimer the primary interest is medium scale local deployments across many systems. This was not intent to cover publicly accessable resources (ie the world-wide web).
For a soft read checkout this article.
Another explanation (with the best diagrams) is found here
The diagram above presents the three roles in HTTPS communication.
- Certificate Authority (CA) "Root"
- Server (Content Provider/RESTful API) "Certificate"
- Client (User/Browser)
The CA, or root certificate, is the global verification for the network; it is the anchor in the "Chain of Trust" that HTTPS tries to establish. It MUST be generated once and installed on all systems in the network. Each server instance will additional have its own certificate; these are generated from the root certificate which allows the certificate to be verified by the CA.
When the Client accesses the Server, it obtains the Server's certificate. The client turns to the CA specified in the cetificate and asks them to verifiy it. If this check passes the Client is confident the content it received is from the server it wishes to speak with.
The TLS encryption of the messages sent is done using the Server's certificate. HTTP is a half-duplex protocol meaning only one side is talking at a time (ie they do not talk over each other). Another unique feature is the Client always initiates communication. The connection setup requires the Client to obtain the server's certificate, which is a public key plus some meta information, thusly when the client encrypts the message using the public key of the server. When the Server receives the request is uses its private key (used in the generation of the certificate) to decrypt the message.
The connection setup described above states the sever sends its certificate and the client verifies it.
What does "verifies the certificate" really mean and how does it work?
The main type of certificate used is the X509 which provides several pieces:
- Common Name
- Alternate Names
- Validate Dates
- Issuer
- Authority Key Identifier
The common name and alternate are used to verify the location you are trying to access the one answering. If the server being accessed responds with the wrong or an unexpected name, there's clearly an issue.
Next the date, valid from and valid to and check to make sure the certificate presented is active and not expired.
Where things get more complicated is the issuer. This field offers the FQDN of the Certificate Authority (or the intermediate that issued it). To confirm this end-entity certificate, one needs an intermediate certificate that matches its Issuer and Authority Key Identifier; the matching intermediate certificate information in the Subject and Subject key identifier.
Typically the intermediate is provided along with the TLS handshake but can be obtained from the CA Issuers field on the server certificate.
The procedure for verification would be the same between the root CA and the intermediate. However the root "should" be installed on the client machine.
Other optional fields are X509v3 CRL Distribution Points and Authority Information Access (OCSP) which provide additional information if the certificate has been revoked.
In an unrurly galaxy striff with interplanetary conflict, who do you know to trust?
When you visit a new planet to meet with the 'Captain Kerk', how certain are you that's the real Kerk and not just an imposter? This supposedly super secret meeting and conversion must not have anyone else listening, how can you ensure that when you meet in a public place for safety?
You define a single entity with the authority to include and remove planets from a galactic federation. Doing so grants them the right to distribute citizenship to their residents, giving them a unique name to identify them by.
Now let's step back from the hyperbole. A root certificate, our single entity, has the authority to represent a region such as federation.galaxy. The idea is that the root certificate is able to validate the ID (Fully Qualified Domain Name in the real world) of any individual under it's duristriction.
When you meet a human you expect them to be kerk.federation.galaxy issued by earth.federation.galaxy. When you meet Kerk at a lovely cafe in some uncharted space, you would ask for his ID, and you expect for him to give you both his certificate and earth's certificate. Given these you can confirm Kerk is from earth, next you verify earth's certificate with your copy of the federations certificate to make sure it's a real earth certificate.
There are three pieces of identity that have now been floated around. You showed up to the meet with our infamous root certificate, ca.federation.galaxy because you don't trust anyone. However, the captain gives you a "certificate chain" which includes his certificate and the intermediate that issued it. Next up, is the CA you brought with you, this is you're golden ticket to verifying all federation members.
Unfortunately, there's a new war between Andoria and Risa, some Andorians blew up the capital monument. Due to thier aggression the federation has revoked the citizenship of Andoria.
How can the federation fail the verification of rejected former members?
They publish a list of revocated intermediates. Online Certificate Status Protocol describes how this list is published and accessed, it's location is in the certificate's meta data. Revoked members get adding to this list and this allows the client to verify the status of each intermediate. The federations OCSP responder confirms that an Andorians's certificate is no longer valid, and returns a signed, successful 'OCSP response' to you. You're able to confirm the signature with the federation certificate.
Let's say we have a RESTful API application. There is one server running the backend of the application which accessed and queried by the client instances.
There are three goals which must be obtained
- Trust
- Identification
- Verification
Trust is the foundation of the HTTPS ecosystem. This is achieved by creating the root CA detailed here and installing it on every system in the network like so. It's best to install the certificate, chain and key ( this is packaged as a PFX for windows )
Identification is done by generating certificates for the server instances. The generated certificates reference the root. TBA on technical detail how that works... detailed here ... These must be installed into the "personal" certificates section of the windows certificate store. The last step it to bind the certificate to the application port, see details here.
Verification is done by all client applications, this is done by simply installing the root certificate into the systems.
lovely cheatsheet poke around for ideas
The windows API that is responsible for these settings is SChannel
Running TLS v1.2 and above ONLY - lower versions are no longer consider secure
-
Certificate algorithms ( you can only bind one at a time with netsh/windows API, so you have to pick // Ideally you would run both to provide the most amount of support ) Running both certificated with OpenSSL ( just call the API twice )
- RSA
- EDCSA ( this is the prefered more secure but there is less cipher support ) ( Required TLS v1.3 ) The catch here is that many IoT or embed devices are not powerful enough (CPU wise) to handle the encryption algorithm. This means targeting the lower end RSA is the minimum standard but cuts off from meeting higher to meet a "best practices" when deploying on the Windows HTTP API.
-
HSTS ( this is just starting to roll out with latest versions of IIS but does not seems to be available in the winhttp API )
- redirect all HTTP to HTTPS ( or just dont offer HTTP )
- also adding this header
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
- Create a CA certificate ( ca.cert.pem and ca.key.pem )
openssl genrsaproduces keyopenssl req -key ca.key.pem -new -x509 -days 18250 -sha256 -extensions v3_caproduces cert
- Install the CA cert by importing it to the MMC certificates snap in ( double clicking also works )
- Create Intermediate CA
openssl reqproduce key- perfome on key to produce CRS (certificate signing request)
openssl ca -batch -extensions v3_intermediate_capassing CRS and root to get intermidate CA cert- create CA chain ( intermidate cert + ca cert )
openssl ca -gencrl- configure OSCP Stapling ( new oscp key,
openssl req -new,openssl ca -batch -extensions ocsp)
- Create server key, combine with intermediate cert ( which refers to root ) to create a server cert
- configure CSR
- install the root CA on all systems
- install the server certificate and bind it to your application port
netsh add sslcert
If you want to use secure communication then you SHALL disables these because this which are enabled by default on the latest versions of Windows 10. msdn msdn 2