SSL / TLS - Revision history

Ardika Sulistija at 18:49, 11 December 2025

2025-12-11T18:49:02Z

← Older revision		Revision as of 18:49, 11 December 2025
Line 449:		Line 449:
	# Server sends ShangeCipherSpec. Indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!		# Server sends ShangeCipherSpec. Indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!
	# Server sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6, and 8). First encrypted message sent from server. Client receives encrypted message and decrypts using key K.		# Server sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6, and 8). First encrypted message sent from server. Client receives encrypted message and decrypts using key K.


	AFTER ALL THIS, THEN IT STARTS THE HTTP connection.		AFTER ALL THIS, THEN IT STARTS THE HTTP connection.

Ardika Sulistija at 18:48, 11 December 2025

2025-12-11T18:48:50Z

← Older revision		Revision as of 18:48, 11 December 2025
Line 440:		Line 440:

	# ClientHello: Client sends over ciphersuites specifications that it supports + ClientRandom (32-bytes value; ensures each handshake produces fresh, unique keys, prevents replay attacks, provides entropy; To be later used with ServerRandom(ServerHello step) and pre-master secret(from key exchange).		# ClientHello: Client sends over ciphersuites specifications that it supports + ClientRandom (32-bytes value; ensures each handshake produces fresh, unique keys, prevents replay attacks, provides entropy; To be later used with ServerRandom(ServerHello step) and pre-master secret(from key exchange).
	2. ServerHello: Server chooses a cipher to use + ServerRandom(same details as ClientRandom).		# ServerHello: Server chooses a cipher to use + ServerRandom(same details as ClientRandom).
	3. Server sends over certificate (webserver certificate and intermediary certificate; also includes the pubkey). The browser then validates the certificates.(half the time of the entire handshake is taken up by this step because its computationally expensive thing for the browser to process)		# Server sends over certificate (webserver certificate and intermediary certificate; also includes the pubkey). The browser then validates the certificates.(half the time of the entire handshake is taken up by this step because its computationally expensive thing for the browser to process)
	4. Server sends over its side ServerKeyExchange (if server is using DH, it sends A, g, n). (RSA part: Server sends those values as Digitally signed (hash encrypted with private key). Browser uses the pubkey from the cert to validate the DS and authenticates that the browser is talking to the intended server/website. The server side has the private key associated with the pubkey.		# Server sends over its side ServerKeyExchange (if server is using DH, it sends A, g, n). (RSA part: Server sends those values as Digitally signed (hash encrypted with private key). Browser uses the pubkey from the cert to validate the DS and authenticates that the browser is talking to the intended server/website. The server side has the private key associated with the pubkey.
	5. Server sends ServerHelloDone, empty message indicating the server negotiation finished.		# Server sends ServerHelloDone, empty message indicating the server negotiation finished.
	6. Client sends ClientKeyExchange (if DH, it sends B value). Browser calculates DH B and key K (pre-master secret (PSK)); Server receives B, and can now calculate the shared key K value. Both client and server concatenates PSK + ClientRandom + ServerRandom → Master Secret, which generates the AES and HMAC. All keys are generated in this step 6, so everyone has all keys needed for the TLS comms.		# Client sends ClientKeyExchange (if DH, it sends B value). Browser calculates DH B and key K (pre-master secret (PSK)); Server receives B, and can now calculate the shared key K value. Both client and server concatenates PSK + ClientRandom + ServerRandom → Master Secret, which generates the AES and HMAC. All keys are generated in this step 6, so everyone has all keys needed for the TLS comms.
	7. Client sends ChangeCipherSpec, indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!		# Client sends ChangeCipherSpec, indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!
	8. Client sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6). First encrypted message sent from client.This is a checker telling the server that it saw everything the server saw.		# Client sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6). First encrypted message sent from client.This is a checker telling the server that it saw everything the server saw.
	9. Server sends ShangeCipherSpec. Indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!		# Server sends ShangeCipherSpec. Indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!
	~~10.~~ Server sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6, and 8). First encrypted message sent from server. Client receives encrypted message and decrypts using key K.		# Server sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6, and 8). First encrypted message sent from server. Client receives encrypted message and decrypts using key K.

	AFTER ALL THIS, THEN IT STARTS THE HTTP connection.		AFTER ALL THIS, THEN IT STARTS THE HTTP connection.

Ardika Sulistija at 18:48, 11 December 2025

2025-12-11T18:48:10Z

← Older revision		Revision as of 18:48, 11 December 2025
Line 434:		Line 434:

	<b>NOTE</b>: The cipher suites are distributed as part of OpenSSL, so you'll have to upgrade that package to gain access to new ones.		<b>NOTE</b>: The cipher suites are distributed as part of OpenSSL, so you'll have to upgrade that package to gain access to new ones.

			====TLS Full 10-Step Handshake (TLS 1.2 & Below)====
			----
			BEFORE ALL THIS IT ESTABLISHES A TCP HANDSHAKE!!

			# ClientHello: Client sends over ciphersuites specifications that it supports + ClientRandom (32-bytes value; ensures each handshake produces fresh, unique keys, prevents replay attacks, provides entropy; To be later used with ServerRandom(ServerHello step) and pre-master secret(from key exchange).
			2. ServerHello: Server chooses a cipher to use + ServerRandom(same details as ClientRandom).
			3. Server sends over certificate (webserver certificate and intermediary certificate; also includes the pubkey). The browser then validates the certificates.(half the time of the entire handshake is taken up by this step because its computationally expensive thing for the browser to process)
			4. Server sends over its side ServerKeyExchange (if server is using DH, it sends A, g, n). (RSA part: Server sends those values as Digitally signed (hash encrypted with private key). Browser uses the pubkey from the cert to validate the DS and authenticates that the browser is talking to the intended server/website. The server side has the private key associated with the pubkey.
			5. Server sends ServerHelloDone, empty message indicating the server negotiation finished.
			6. Client sends ClientKeyExchange (if DH, it sends B value). Browser calculates DH B and key K (pre-master secret (PSK)); Server receives B, and can now calculate the shared key K value. Both client and server concatenates PSK + ClientRandom + ServerRandom → Master Secret, which generates the AES and HMAC. All keys are generated in this step 6, so everyone has all keys needed for the TLS comms.
			7. Client sends ChangeCipherSpec, indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!
			8. Client sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6). First encrypted message sent from client.This is a checker telling the server that it saw everything the server saw.
			9. Server sends ShangeCipherSpec. Indicates everything is fine and ready to start encryption. NOT A HANDSHAKE MESSAGE!
			10. Server sends Finished. Sends the hash of all prior HANDSHAKE MESSAGES (steps 1-6, and 8). First encrypted message sent from server. Client receives encrypted message and decrypts using key K.

			AFTER ALL THIS, THEN IT STARTS THE HTTP connection.

Ardika Sulistija at 05:24, 19 November 2024

2024-11-19T05:24:23Z

← Older revision		Revision as of 05:24, 19 November 2024
Line 138:		Line 138:


	=====How to install Let's Encrypt with Bitnami's HTTPS Configuration Tool, <b>bncert-tool</b>=====		=====<u>How to install Let's Encrypt with Bitnami's HTTPS Configuration Tool, <b>bncert-tool</b></u>=====
	~~----~~

	[+] Generate and Install a Let's Encrypt SSL Certificate for a Bitnami Application </br>		[+] Generate and Install a Let's Encrypt SSL Certificate for a Bitnami Application </br>
Line 159:		Line 159:


	=====How to install Let's Encrypt with <b>Certbot</b> (Super Easy)=====		=====<u>How to install Let's Encrypt with <b>Certbot</b> (Super Easy)</u>=====
	~~----~~
	The following steps were done on Amazon Linux 2.		The following steps were done on Amazon Linux 2.

Line 276:		Line 276:


	=====Apache VirtualHost configuration when using Let's Encrypt=====		=====<u>Apache VirtualHost configuration when using Let's Encrypt</u>=====


	The Certbot script creates the <b><VirtualHost...></b> block for 443 in the <b>/etc/httpd/conf/httpd-le-ssl.conf</b> file, instead of the default <b>[[Apache\|Apache]]</b> configuration file (<b>/etc/httpd/conf/httpd.conf</b>).		The Certbot script creates the <b><VirtualHost...></b> block for 443 in the <b>/etc/httpd/conf/httpd-le-ssl.conf</b> file, instead of the default <b>[[Apache\|Apache]]</b> configuration file (<b>/etc/httpd/conf/httpd.conf</b>).
Line 304:		Line 303:


	=====How to renew Let's Encrypt cert (Certbot)=====		=====<u>How to renew Let's Encrypt cert (Certbot)</u>=====

	sudo certbot renew		sudo certbot renew
Line 315:		Line 314:
	sudo certbot renew -q		sudo certbot renew -q

	=====How to set up automatic renewal=====
			=====<u>How to set up automatic renewal</u>=====


	Instructions from: https://certbot.eff.org/instructions?ws=apache&os=pip		Instructions from: https://certbot.eff.org/instructions?ws=apache&os=pip
Line 324:		Line 325:


	=====How to renew Lets Encrypt cert (Non-Certbot way)=====		=====<u>How to renew Lets Encrypt cert (Non-Certbot way)</u>=====
	~~-----~~

	$ sudo service apache2 stop # This stops the web server		$ sudo service apache2 stop # This stops the web server
Line 332:		Line 332:


	=====~~Howto~~ Delete Certbot Certificate (Cleanly)=====		=====<u>How to Delete Certbot Certificate (Cleanly)</u>=====
	~~----~~

	Luckily, a feature exists to perform the deletion automatically for you. This command will offer an index from which you can select the domain name to delete:		Luckily, a feature exists to perform the deletion automatically for you. This command will offer an index from which you can select the domain name to delete:

Ardika Sulistija at 05:19, 19 November 2024

2024-11-19T05:19:29Z

← Older revision		Revision as of 05:19, 19 November 2024
Line 277:		Line 277:

	=====Apache VirtualHost configuration when using Let's Encrypt=====		=====Apache VirtualHost configuration when using Let's Encrypt=====
	~~----~~


Line 306:		Line 305:

	=====How to renew Let's Encrypt cert (Certbot)=====		=====How to renew Let's Encrypt cert (Certbot)=====
	~~----~~
	sudo certbot renew		sudo certbot renew

Line 316:		Line 315:
	sudo certbot renew -q		sudo certbot renew -q

	======How to set up automatic renewal======		=====How to set up automatic renewal=====
	~~----~~

	Instructions from: https://certbot.eff.org/instructions?ws=apache&os=pip		Instructions from: https://certbot.eff.org/instructions?ws=apache&os=pip

Ardika Sulistija at 05:17, 19 November 2024

2024-11-19T05:17:02Z

← Older revision		Revision as of 05:17, 19 November 2024
Line 159:		Line 159:


	=====How to install Let's Encrypt with <b>Certbot</b> ~~on Amazon Linux 2~~ (Super Easy)=====		=====How to install Let's Encrypt with <b>Certbot</b> (Super Easy)=====
	----		----
			The following steps were done on Amazon Linux 2.

	The instructions I used to set up Let's Encrypt SSL using <b>Certbot</b> on Amazon Linux 2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html#letsencrypt</br>		The instructions I used to set up Let's Encrypt SSL using <b>Certbot</b> on Amazon Linux 2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html#letsencrypt</br>
Line 268:		Line 268:
	* After installing SSL cert and creating backups, I created a <b>[[Cron\|cron job]]</b>. By default, Certbot generates host certificates with a short, 90-day expiration time. If you have not configured your system to call the command automatically, you must re-run the certbot command manually before expiration. Certbot developers suggest running the command at least twice daily. This guarantees that any certificate found to be compromised is promptly revoked and replaced. Refer to this page on how to configure the automated certificate renewal.		* After installing SSL cert and creating backups, I created a <b>[[Cron\|cron job]]</b>. By default, Certbot generates host certificates with a short, 90-day expiration time. If you have not configured your system to call the command automatically, you must re-run the certbot command manually before expiration. Certbot developers suggest running the command at least twice daily. This guarantees that any certificate found to be compromised is promptly revoked and replaced. Refer to this page on how to configure the automated certificate renewal.
	** <b>Refer to this [[Cron\|page]] on how I configured automated certificate renewal using cron job.</b>		** <b>Refer to this [[Cron\|page]] on how I configured automated certificate renewal using cron job.</b>

			<b>How I installed Let's Encrypt using Certbot on Amazon Linux 2023: </b> https://certbot.eff.org/instructions?ws=apache&os=pip






Line 298:		Line 304:
	</IfModule>		</IfModule>


			=====How to renew Let's Encrypt cert (Certbot)=====
			----
			sudo certbot renew

			Tested on Amazon Linux 2023.

			Instructions from: https://certbot.eff.org/instructions?ws=apache&os=pip

			Quiet method:
			sudo certbot renew -q

			======How to set up automatic renewal======
			----

			Instructions from: https://certbot.eff.org/instructions?ws=apache&os=pip

			Per certbot's instructions - We recommend running the following line, which will add a cron job to the default crontab.

			echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" \| sudo tee -a /etc/crontab > /dev/null


	=====How to renew Lets Encrypt cert=====		=====How to renew Lets Encrypt cert (Non-Certbot way)=====
	-----		-----

Ardika Sulistija: Created page with "ADD NOTES:
What Happens in a TLS Handshake?: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
Good Video: https://www.youtube.com/watch?v=T4Df5_cojAs
====What is SSL?==== ---- How Does SSL Work?: https://www.cloudflare.com/learning/ssl/how-does-ssl-work/
SSL stands for Secure Sockets Layer. A protocol for encrypting and securing communications that take place on the Internet. SSL was replaced..."

2024-09-11T14:26:32Z

Created page with "ADD NOTES: What Happens in a TLS Handshake?: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ Good Video: https://www.youtube.com/watch?v=T4Df5_cojAs ====What is SSL?==== ---- How Does SSL Work?: https://www.cloudflare.com/learning/ssl/how-does-ssl-work/ SSL stands for Secure Sockets Layer. A protocol for encrypting and securing communications that take place on the Internet. SSL was replaced..."

New page

ADD NOTES:

What Happens in a TLS Handshake?: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
Good Video: https://www.youtube.com/watch?v=T4Df5_cojAs

====What is SSL?====
----

How Does SSL Work?: https://www.cloudflare.com/learning/ssl/how-does-ssl-work/

SSL stands for Secure Sockets Layer. A protocol for encrypting and securing communications that take place on the Internet. SSL was replaced by an updated protocol called TLS (Transport Layer Security) some time ago, but "SSL" is still widely used for this protocol.

Main purpose: Securing communications between a client and a server, but it can also secure email, VoIP, and other communications over unsecured networks.

=====These are the essential principles to grasp for understanding how SSL/TLS works:=====

* Secure communication begins with a TLS handshake, in which the two communicating parties open a secure connection and exchange the public key
* During the TLS handshake, the two parties generate session keys, and the session keys encrypt and decrypt all communications after the TLS handshake
* Different session keys are used to encrypt communications in each new session
* TLS ensures that the party on the server side, or the website the user is interacting with, is actually who they claim to be
* TLS also ensures that data has not been altered, since a message authentication code (MAC) is included with transmissions

With TLS, both HTTP data that users send to a website (by clicking, filling out forms, etc.) and the HTTP data that websites send to users is encrypted. Encrypted data has to be decrypted by the recipient using a key.

=====The TLS handshake=====

TLS communication sessions begin with a TLS handshake. A TLS handshake uses something called asymmetric encryption, meaning that two different keys are used on the two ends of the conversation. This is possible because of a technique called public key cryptography.

In public key cryptography, two keys are used:
# a public key, which the server makes available publicly,
# and a private key, which is kept secret and only used on the server side.

Data encrypted with the public key can only be decrypted with the private key, and vice versa.

!! During the TLS handshake, the client and server use the public and private keys to exchange randomly generated data, and this random data is used to create new keys for encryption, called the [[#Symmetric encryption with session keys|session keys]].

Asymmetric (Public Key) Encryption
"Hello" + Public Key = "362oy4h2ilef" + Private Key = "Hello"

=====Symmetric encryption with session keys=====

Unlike asymmetric encryption, in symmetric encryption the two parties in a conversation use the same key.

After the TLS handshake, both sides use the same session keys for encryption. Once session keys are in use, the public and private keys are not used anymore. Session keys are temporary keys that are not used again once the session is terminated. A new, random set of session keys will be created for the next session.

Symmetric Encryption
"Hello" + Session Key = "362oy4h2ilef" + Session Key = "Hello"

=====Authenticating the origin server=====

TLS communications from the server include a Message Authentication Code, or MAC, which is a digital signature confirming that the communication originated from the actual website. This authenticates the server, preventing man-in-the-middle attacks and domain spoofing. It also ensures that the data has not been altered in transit.

=====What is an SSL certificate?=====

An SSL certificate is a file installed on a website's [https://www.cloudflare.com/learning/cdn/glossary/origin-server/ origin server].

It's simply a data file containing the public key and the identity of the website owner, along with other information. Without an SSL certificate, a website's traffic can't be encrypted with TLS.

Technically, any website owner can create their own SSL certificate, and such certificates are called self-signed certificates. However, browsers do not consider self-signed certificates to be as trustworthy as SSL certificates issued by a certificate authority.

=====How does a website get an SSL certificate?=====

Website owners need to obtain an SSL certificate from a certificate authority, and then install it on their web server (often a web host can handle this process).

A certificate authority is an outside party who can confirm that the website owner is who they say they are. They keep a copy of the certificates they issue.

=====What is a CSR?=====

Certificate Signing Request (CSR)

A vital component in the process of obtaining your digital certificate for your web server. It is a block of encoded text that contains information about the entity that's requesting the certificate, including the organization's name, domain name, locality, and country.

When an entity desires a digital certificate from a Certificate Authority, it first generates a certificate signing request which includes the entity's public key. The Certificate Authority will then use the details in that CSR to create the final digital certificate that will be issued back to you.

It's important to note the private key associated with the request remains securely with the requester and is never sent out to the Certificate Authority because this insures the confidentiality of that given key pair. Once the Certificate Authority validates the entity's credentials and processes the CSR, the resulting certificate will be returned to the entity and can be installed on all of its server to facilitate secure communications.

=====Is it possible to get a free SSL certificate?=====

Yes. Cloudflare offers free SSL certificates, and there is also [[#Let's Encrypt |Let's Encrypt]].

=====What is the difference between HTTP and HTTPS?=====

The S in "HTTPS" stands for "secure." HTTPS is just HTTP with SSL/TLS. A website with an HTTPS address has a legitimate SSL certificate issued by a certificate authority, and traffic to and from that website is authenticated and encrypted with the SSL/TLS protocol.

Learn more about HTTPS: [https://www.cloudflare.com/learning/ssl/what-is-https/ What is HTTPS?]

=====Another description of how SSL connections work=====

If you've ever connected to a website using an HTTPS connection, you've been part of the public key infrastructure (PKI).

If you want to establish a secure connection to a website like dikapedia.com, you would go into your web browser and type in https://dikapedia.com. Your browser will then go to a trusted third party called the Certificate Authority, and they're going to ask them for a copy of the web server's public key. Then your web browser will pick a long random string of numbers, and it's going to use that as a shared secret key.

So it uses an asymmetric algorithm for bulk encryption, something like AES, as we start transferring data back and forth between your web browser and the web server. But first, you have to get that randomly chosen shared secret key over to the web server securely. And for that, it's actually going to use public key encryption (known as asymmetric encryption.

Now, using the public key that you downloaded from the Certificate Authority, your computer will then encrypt that random shared secret key that you just randomly created.

As an example, let's use a short number like 1234567 as thee shared secret. Once you encrypt that using the server's public key, which anyone in the world has access to, you can then send it over the Internet to the web server. Now, because it is encrypted with the public key, no one on the internet is going to be able to decrypt it unless they have the private key, and the only person who has that private key is the web server.

As we go across the internet, no one can see the fact that we are going to use 1234567 as the shared secret code. Once the web server receives that encrypted cipher text, it is going to use the server's private key to decrypt it and then get it back to that shared secret key that you submitted. Now I can read the plain text and I know the number is 1234567.

So far, this is all using asymmetrical encryption. Up to this point, everything that was done has to do with asymmetric encryption, but now that both you and the web server know the shared secret key, we can switch over and create a symmetric tunnel. To do this, we're going to use something like AES to create a TLS or SSL tunnel over the internet, and then communicate safely and securely through that tunnel to make sure nobody can see the data you're entering. This is going to be able to ensure that we have confidentiality because only we have access to this shared tunnel because we both have that shared secret key. And because the web server is the only device in the entire world that has its private key, you can be assured that only the web server knows who it is and who it claims to be when you sent that code over. This way, we have authentication. You know it's dikapedia.com. This gives us the identity of the server and it also lets your web browser know it can trust me.

If all of that occurs successfully, you're going to see the little padlock in the browser, indicating that you can communicate securely with each other over this encrypted tunnel.

====Let's Encrypt====
----

Let's Encrypt - Free SSL/TLS Certificates, a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security encryption at no charge. The certificate is valid for 90 days, during which renewal can take place at any time. [Wikipedia]

Let's Encrypt - Recommended to use certbot: https://certbot.eff.org/
https://certbot.eff.org/lets-encrypt/centosrhel7-apache

Bitnami - OR you can use bncert-tool

Let’s Encrypt does the following:
* Confirms that you have control over the DNS domain being used, by having you create a DNS TXT record using the value that it provides.
* Obtains an SSL/TLS certificate.
* Modifies the Apache-related scripts to use the SSL/TLS certificate and redirects users browsing the site in HTTP mode to HTTPS mode.

=====How to install Let's Encrypt with Bitnami's HTTPS Configuration Tool, bncert-tool=====
----

[+] Generate and Install a Let's Encrypt SSL Certificate for a Bitnami Application 
https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/

[+] Learn about the Bitnami HTTPS Configuration Tool
https://docs.bitnami.com/aws/how-to/understand-bncert/

To run the Bitnami HTTPS Configuration Tool, follow the instructions below:
Download the Bitnami HTTPS Configuration Tool:
wget -O bncert-linux-x64.run https://downloads.bitnami.com/files/bncert/latest/bncert-linux-x64.run
sudo mkdir /opt/bitnami/bncert
sudo mv bncert-linux-x64.run /opt/bitnami/bncert/
sudo chmod +x /opt/bitnami/bncert/bncert-linux-x64.run
sudo ln -s /opt/bitnami/bncert/bncert-linux-x64.run /opt/bitnami/bncert-tool

Run the Bitnami HTTPS Configuration Tool:
sudo /opt/bitnami/bncert-tool

=====How to install Let's Encrypt with Certbot on Amazon Linux 2 (Super Easy)=====
----

The instructions I used to set up Let's Encrypt SSL using Certbot on Amazon Linux 2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html#letsencrypt

Amazon Linux 2023:
https://docs.aws.amazon.com/linux/al2023/ug/SSL-on-amazon-linux-2023.html

Follow the instructions above, it's really easy. Certbot pretty much does all the configuration for you, and will let you know where the key files are located and what not.

NOTE!!!: Before proceeding with the following steps, make sure you have the following DNS records:
* A record - @ - 23.20.238.64
* A record - www - 23.20.238.64

My output when I ran certbot, NOTE the ending is where info is provided:
[root@ip-172-31-33-239 ec2-user]# certbot
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): <email>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: dikapedia.com
2: www.dikapedia.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for dikapedia.com
http-01 challenge for www.dikapedia.com
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf
Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration
Deploying Certificate to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting vhost in /etc/httpd/conf/httpd.conf to ssl vhost in /etc/httpd/conf/httpd-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://dikapedia.com and
https://www.dikapedia.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=dikapedia.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.dikapedia.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/dikapedia.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/dikapedia.com/privkey.pem
Your cert will expire on 2020-04-19. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

* Your certificate and chain have been saved at:
::/etc/letsencrypt/live/dikapedia.com/fullchain.pem
* Your key file has been saved at:
::/etc/letsencrypt/live/dikapedia.com/privkey.pem
* [[#Apache VirtualHost configuration when using Let's Encrypt|Certbot created an SSL vhost for 443 at /etc/httpd/conf/httpd-le-ssl.conf]]

* Your cert will expire on 2020-04-19.
* To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option.
* To non-interactively renew *all* of your certificates, run "certbot renew"
* Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt.
* You should make a secure [[Archiving and Compression|backup]] of this folder now!!! This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
* After installing SSL cert and creating backups, I created a [[Cron|cron job]]. By default, Certbot generates host certificates with a short, 90-day expiration time. If you have not configured your system to call the command automatically, you must re-run the certbot command manually before expiration. Certbot developers suggest running the command at least twice daily. This guarantees that any certificate found to be compromised is promptly revoked and replaced. Refer to this page on how to configure the automated certificate renewal.
** Refer to this [[Cron|page]] on how I configured automated certificate renewal using cron job.

=====Apache VirtualHost configuration when using Let's Encrypt=====
----

The Certbot script creates the <VirtualHost...> block for 443 in the /etc/httpd/conf/httpd-le-ssl.conf file, instead of the default [[Apache|Apache]] configuration file (/etc/httpd/conf/httpd.conf).

In the [[Apache|Apache]] configuration file (/etc/httpd/conf/httpd.conf), there is a line including the httpd-le-ssl.conf file:
IncludeOptional conf.d/*.conf
Include /etc/httpd/conf/httpd-le-ssl.conf

The Vhost block for 443 contains the same first 6 lines as for Vhost *:80 ([[Apache#Redirects_and_Virtual_Hosts |example]]).
* Notice the Include /etc/letsencrypt/options-ssl-apache.conf line with the SSLCertificateFile and SSLCertificateKeyFile.
# cat /etc/httpd/conf/httpd-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot "/var/www"
ServerName dikapedia.com
ServerAlias www.dikapedia.com
RewriteEngine on
RedirectMatch ^/$ /wiki/
Options FollowSymLinks

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/dikapedia.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/dikapedia.com/privkey.pem
</VirtualHost>
</IfModule>

=====How to renew Lets Encrypt cert=====
-----

$ sudo service apache2 stop # This stops the web server
$ sudo /usr/bin/letsencrypt renew # Renew certificate through Let's Encrypt
$ sudo service apache2 start # Starts web server back up

=====Howto Delete Certbot Certificate (Cleanly)=====
----

Luckily, a feature exists to perform the deletion automatically for you. This command will offer an index from which you can select the domain name to delete:
$ sudo certbot delete

----

Another good AWS article: https://aws.amazon.com/blogs/compute/extending-amazon-linux-2-with-epel-and-lets-encrypt/

====GoDaddy SSL ====
----

Link: https://www.godaddy.com/help/install-ssl-certificates-16623

====Namecheap SSL ====
----

* Generating CSR on Apache + OpenSSL/ModSSL/Nginx + Heroku:
https://www.namecheap.com/support/knowledgebase/article.aspx/9446/14/generating-csr-on-apache--opensslmodsslnginx--heroku/#1

* How Do I Activate an SSL Certificate
https://www.namecheap.com/support/knowledgebase/article/794/67/how-do-i-activate-an-ssl-certificate/

* Installing an SSL certificate on Apache
https://www.namecheap.com/support/knowledgebase/article.aspx/9423/33/installing-an-ssl-certificate-on-apache

====[[CloudEndure (AWS) | SSL + MITM PROXIES + CLOUDENDURE]]====
----

====SSL content fixers====
----

https://wordpress.org/plugins/really-simple-ssl/

https://wordpress.org/plugins/ssl-insecure-content-fixer/

====How to check what TLS version an OS supports (CentOS5)====
----

* https://www.2daygeek.com/check-supported-tls-ssl-version-ciphers-linux/

openssl ciphers -v | awk '{print $2}' | sort | uniq
SSLv2
SSLv3

* NOTE I think the below command is misleading/wrong (do not use the below):
$ for proto in 1 1_1 1_2 1_3; do openssl s_client -connect example.com:443 "-tls${proto}" 2>/dev/null < <(sleep 1; echo q) | grep Protocol | uniq; done
Protocol : TLSv1

====How to check what SSL protocol versions are supported on a Linux system====
----
* https://www.2daygeek.com/check-supported-tls-ssl-version-ciphers-linux/

openssl ciphers -v | awk '{print $2}' | sort | uniq

====How to check what Ciphers are available (CentOS5)====
----
* https://community.tenable.com/s/article/How-to-check-the-SSL-TLS-Cipher-Suites-in-Linux-and-Windows
* https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-hardening_tls_configuration
* https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-hardening_tls_configuration#sec-Working_with_Cipher_Suites_in_OpenSSL
/usr/bin/openssl ciphers -v

Cipher Suites are named combinations of:

Key Exchange Algorithms (RSA, DH, ECDH, DHE, ECDHE, PSK)
Authentication/Digital Signature Algorithm (RSA, ECDSA, DSA)
Bulk Encryption Algorithms (AES, CHACHA20, Camellia, ARIA)
Message Authentication Code Algorithms (SHA-256, POLY1305)
Type of Encryption TLS v1.3, v1.2, v1.1, v1.0 or SSL v3, v2

Here is an example of a TLS v1.2 cipher suite from Openssl command 'openssl ciphers -v' output:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
Key Exchange: ECDHE
Signature: RSA
Bulk Encryption: AES256-GCM
Message Authentication: SHA384

* To get a list of all cipher suites supported by your installation of OpenSSL, use the openssl command with the ciphers subcommand as follows:
$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'
or
$ openssl ciphers -v | column -t

* Pass other parameters (referred to as cipher strings and keywords in OpenSSL documentation) to the ciphers subcommand to narrow the output. Special keywords can be used to only list suites that satisfy a certain condition. For example, to only list suites that are defined as belonging to the HIGH group, use the following command:
$ openssl ciphers -v 'HIGH'

NOTE: The cipher suites are distributed as part of OpenSSL, so you'll have to upgrade that package to gain access to new ones.