OPS345 Lab 6: Difference between revisions

From Littlesvr Wiki
Jump to navigation Jump to search
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
= THIS PAGE IS A DRAFT, NOT READY FOR USE YET =
= Encryption, certificates, etc. =
In this lab we'll start working with email. It's an ancient concept, but it's still relied on for most business communication. New and exciting messaging platforms come and go, but email has been around for decades and isn't going anywhere soon.


= Email services components =
Encryption means converting plain text (something you can read/use, it doesn't need to be text) into cyphertext. The cyphertext created by a good encryption algorithm is impossible (or, for weak algorithms: at least impractical) to decrypt (covert back into plain text) without a key.
Originally there was only one "email" protocol: SMTP. It was designed to address, route, and receive messages for a destination user on a destination server. Later an extra couple of protocols (POP3 and IMAP) were developed so that people wouldn't have to read their email on the command-line on the SMTP server. Now there are many components, making a powerful, reliable, but complex system. Here's a simplified diagram of what typically happens when you send an email to someone else:


[[File:Email-servers.png|800px|border|center]]
You've been using public key cryptography for your entire life (unless you were born before the 1990s). And you've been setting up public key cryptography for yourself since at least OPS245. If you actually understand how this stuff works: you'll be far ahead of the average sysadmin.


By the end of this course you should be familiar enough with all these components to be able to speak about them comfortably.
We don't have the time to do a comprehensive overview of cryptography, so I strongly encourage you to put the book '''Crypto''' by '''Steven Levy''' on your "must-read" list. Unfortunately they no longer have copies for check-out at the library, but I'm sure you can still find a way to read it. I have yet to see a better introduction to encryption. It's not a course reqirement - but if you don't want to be clueless about security fundamentals online - read that book and understand it. It reads like a novel, and it's perfectly readable even if you have no interest in math:


We'll set up an SMTP server in this lab and an IMAP server in the next lab.
[[Image:crypto.jpeg|center|"crypto" by Steven Levy]]


= New VM: email =
In a nutshell, here are the most important points, the absolute minimum you need to be comfortable with this:


* Create a new VM, similar to the www VM you created earlier. Make sure that it:
* Public key encryption (also called assymetric encryption) uses two keys: a public key and a private key.
** Is in '''vpc-ops345''' (where no public IP address should be assigned by default).
* The two keys are permanently tied to each other by complex mathematics (read the book to get a feel for the fundamentals). You can't mix one public key with an unrelated private key.
** Has the IP address '''10.3.45.12'''
* The private key is like your password, you never give it to anyone. The public key is of no value to attackers, so there's no point in trying to protect it.
** Gets an extra '''4GB EBS''' volume, not to be deleted automatically if the VM is deleted.
* Anyone can encrypt something with the public key, but only the private key can be used to decrypt that.
** Is in a new security group named '''ops345emailsg''', which will allow SSH acccess from the router only and SMTP access from anywhere.
* Anyone can verify that a file signed using the private key has not been modified except by the owner of the private key.
** Name the new instance: '''email'''
* A certificate is a public key typically signed by a third party's private key.
* After it starts: do some configuration you should be very comfortable with by now:
* Symmetric encryption only has one private key, no public key. That makes it very hard to use with strangers on the internet.
** Set up port forwarding on the router so you can SSH to email via port 2212 on the router. The email server is going to have its own public IP, but remember we're pretending that we're monitoring all SSH traffic using special software on the router machine.
* Hashing is used a lot in cryptography, but it's not an encryption tool.
** Create a new user and delete ec2-user.
** Set the hostname to '''email.yoursenecaid.ops345.ca'''
** Allocate a new, permanent static IP named email_public_ip and associate it with your email server.


== DNS records ==
With those fundamentals you should be able to follow this diagram which describes how SSH key authentication works. The diagram is from Sébastien Saunier's blog (which is no longer online):


Email used as you're used to it requires a couple of DNS entries. One A record for the server, and on MX record for your domain.
[[Image:ssh_connection_explained.png|thumb|center|600px|A diagram explaining how public / private keys work.]]


* Log in to your [http://ops345.ca Bindistrar].
== Certificate Authorities (CAs) ==
* Create an A record for email.yoursenecaid.ops345.ca with the static IP you assigned to your email server. This is just a typical A record.
* Create an MX record with the value email.yoursenecaid.ops345.ca.
** This record is for other people's email servers who want to send email to anyone@yoursenecaid.ops345.ca
** It specifies that the receiving SMTP server for yoursenecaid.ops345.ca is email.yoursenecaid.ops345.ca
** The priority is there for when you have one or more backup email servers. You would if this email server were important, but in this course you don't so you can pick any number for the priority.


Remember that DNS records are cached, so if you make a mistake: you'll need for the TTL to expire before you can test your updated records. One way too give yourself two chances to get it right is to first test your MX record on the router. Then if it's wrong: you can test your second attempt on your workstation before the TTL expires on the router's caching DNS server.
The problem with assymetric encryption is the distribution of public keys. The encryption strength is meaningless if the client can't be sure it has the unmodified public key for the server. That's where a third party gets involved. This third party is called a Certificate Authority.


* Test your MX record on the router:
The exact same concepts from the section above are used for CA-signed certificates. There's just a third party involved - which makes it seem like magic for too many people, including professionals in our field.


[[File:AWSDigEmail.png|border|center]]
If you have any ambitions in this field: set a goal for yourself to understand this stuff fully. At least eventually, if not now.


== Storage ==
=== Setup on the server ===


For the www VM we set up an external storage device so that we wouldn't lose our website if the server was damaged or deleted. We'll do the same for the email VM. You can look back at lab 3 if you need a reminder for how to do the following steps.
Let's take a web browser and web server for an example - since that's the most common use of this setup.


* Create a volume group '''vg_email''' with the second drive as the only physical volume.
# First the web server administrator needs to generate a key pair, roughly the same as what you've been using for SSH (but using different commands).
* Create a logical volume '''lv_email'''
# The server admin needs to have the public key from that pair signed by a CA which browsers will accept as reliable. There are many such CAs, you can look in your browser's settings to see a full list. Typically people choose the cheapest option that will work in their setup. That's around 60$ a year.
# The admin needs to pay the CA for the service. There's only one free option available which we'll use in this course.
# The CA will use their private key to sign the web server's public key. That will allow people who already have the CA's public key to verify that the web server's public key has not been modified (by anyone other than the people who have access to any trusted CAs private key).
# The server admin can download this signed public key (a.k.a. a certificate) from the CA.
# The server admin will configure the web server to use the server's private key and the CA-signed version of its pair public key for secure communication over HTTPS.


{{Admon/important|Don't get locked out|With the setup we're building all the emails will be stored in each user's home directory. That means '''lv_email''' will need to be mounted on '''/home'''. That makes it tricky because other important things (like your SSH keys) are stored under /home as well, so be careful with the following steps, you may end up locking yourself out of your VM, and you'll have to rebuild it.}}
[[File:ServerCA.png|800px|border|center]]


* Create a temporary directory /tmp/home and mount lv_email there.
A certificate will always be linked to an FQDN. That mostly makes sense since web browsers connect to a web server using a domain name. Sometimes that's a pain in the neck for the administrator (you'll see why later) and the concept of "wildcard certificate" exists, but I was never able to set one up to work properly.
* Move all the contents of /home to /tmp/home
* Edit your fstab to make sure lv_email gets mounted automatically on /home when your system boots.
* Hold your breath and reboot. If you did it right: you should be able to ssh back in and everything will look the same, except now there's a lost+found directory in /home, which tells you that there's a filesystem mounted on there.


== SMTP server: Postfix ==
=== Client communicating with server ===


There are many SMTP server software on Linux to choose from. Postfix is the most used commonly used so that's the one we're going to use. It can be configured to do all sorts of advanced and interesting things, but we'll keep it simple. Once you feel less overwhelmed with all the exotic configuration options: it will help you to read the description of what those options do, over time the meaning of those comments will become more and more clear.
Now that the server is configured, let's look at what happens when a web browser connects to a web server using HTTPS.  


Postfix is installed by default on Amazon Linux, but it only listens on localhost, it will not accept inbound connections to port 25 even if the firewall allows access to that port.
# The web browser connects to a web server, expecting to establish encrypted communication.
# The web server will send to the client its CA-signed public key.
# The browser came installed with a list of trusted CAs' public keys. Good luck figuring out how this list was compiled by whom when and how it's kept up to date. Let's just assume for now that those are all trustworthy, since everyone else assumes the same. It uses the appropriate CA's public key from that list to verify the server's public key.
# At this point a combination of signing, encryption, and exchange of symmetrical encryption keys can be used to establish a connection where all traffic in both directions is encrypted.


* Use the '''ss''' command to see what ports are open (i.e. there is a service listening on that port):
[[File:BrowserCA.png|800px|border|center]]
[[File:AWSssSMTPlocalhost.png|800px|border|center]]
* Edit '''/etc/postfix/main.cf''' and change four of the options:
** Set '''mydomain''' to yoursenecaid.ops345.ca
** Set '''myorigin''' to $mydomain. This is appended to your username when you send email directly from the server. It doesn't have to be the same as $mydomain, but it makes sense for it to be the same in most cases.
** Set '''inet_interfaces''' to all. This will configure Postfix to listen for external incomming connections, rather than just connections from localhost.
** Change '''mydestination''' to include $mydomain. This will tell postfix that when it sees an email for anyone@yoursenecaid.ops345.ca: it should deliver it rather than forward it to a different SMTP server.
* Restart the Postfix service. Check the service status, /var/log/messages, and /var/log/maillog to confirm that it restarted successfully.
* Run '''ss''' again, learn to see the difference between a service that listens on localhost and a service that listens on all interfaces:
[[File:AWSSsSMTPOpen.png|800px|border|center]]


=== Test receiving email ===
== Self-signed certificates ==


People often think of SMTP servers as "sending" servers, but they are responsible for receiving email too. Since setting up a full email client involves many steps, and at least two services: we'll test access to the SMTP server manually.
Options exist if you need encrypted communication to your web or email server but you're not willing to pay for a CA or deal with the complexities required by Let's Encrypt:
# You can self-sign a certificate, and add that certificate directly into your client software. If you have full control over all your client software: this is more secure and reliable than using a typical CA.
# You can set up your own certificate authority (it takes one command to do that) to sign whatever certificates you want, and configure your client software to trust your CA. Again, this is more secure and reliable than relying on potentially untrustworthy CAs.


* See if you can connect from your workstation to your SMTP server using telnet. If the connection is successful: run a single SMTP protocol command just because you can:
We won't be doing either of those techniques in this course because their application requires closer knowledge of the business where they're used, and therefore it's too specific for this course.
[[File:AWSTelnet25.png|border|center]]
* You can use the '''quit''' command or the escape sequence ^] to get out of that session.
* Now use whatever email service you want (e.g. myseneca, or your personal account) to send an email to yourusername@yourusername.ops345.ca. Note that you don't need any special configuration on the sender's email client or server. All someone needs to know to send email to you is in your server's MX record.
** Before you send it: run '''tail -f /var/log/maillog''' in a terminal so you can see what happens when a message arrives. You can press enter a few times to insert some blank lines so you can more easily separate unrelated messages.[[File:AWSMaillogReceivedMail.png|800px|border|center]]
** There's a lot of log for a single email. I typically look for '''from''', '''to''', and '''status=sent'''. If the status is something different: I start looking at other information.
* "Delivered to mailbox" means that Postfix decided it is the destination for this particular message and saves it where it was configured to save it.


=== Use Maildir and dovecot-lda ===
= HTTPS for your web server =


By default Postfix saves emails in the file '''/var/mail/username''' in the MBOX format. That means all the emails you get will be appended to this file. That works fine under normal circumstances but most people don't use MBOX for serious email servers. We'll configure Postfix to save messages in the Maildir format, under each user's home directory.
Generally-trusted CAs' services cost money. We're going to avoid extra costs in this course, and will use the one and only free CA which is trusted by a typical browser: '''Let's Encrypt'''.


We'll use dovecot-lda as a LDA. It's an application that comes with the Dovecot package.
Let's Encrypt won't give you a certificate for more than 3 months, which is why the paid-for CAs still exist. They encourage you to set up automatic renewals of your certificate using their custom software, which is not always doable or even desireable. But it's free and 3 months is good enough for us.


* Install dovecot, but don't start or enable the service. Leave the Dovecot configuration for the next lab.
== Create your signed certificate ==
* Edit /etc/postfix/main.cf and add the following mailbox_command, to tell Postfix to deliver using dovecot-lda:<pre>mailbox_command = /usr/libexec/dovecot/dovecot-lda -f "$SENDER" -a "$RECIPIENT"</pre>
* Restart postfix.
* Edit /etc/dovecot/conf.d/10-mail.conf and add the following mail_location parameter, to tell dovecot-lda where to store emails it is asked to store and in which format:<pre>mail_location = maildir:~/Maildir</pre>
* No need to restart any service after changing that, dovecot-lda is executed as an application for every email that Postfix wants delivered.
* Send yourself another email and find where it ended up. The maildir format isn't meant for reading on the command-line, but you should be able to find a newly received message so that you can troubleshoot when it's not working properly.


=== Aliases ===
The steps below follow relevant instructions from the [https://help.datica.com/hc/en-us/articles/360044373551-Creating-and-Deploying-a-LetsEncrypt-Certificate-Manually Let's Encrypt Creating and Deploying a LetsEncrypt Certificate Manually] page.


Sometimes you want to receive emails which are sent to different addressed. For example the system administrator typically receives emails sent to postmaster, webmaster, hostmaster, and root. Also dovecot-lda will not deliver email to root at all as a security measure.
* Install certbot in your workstation using apt or the Software Manager. This is a command-line-only application.
* Run <syntaxhighlight lang="bash">certbot certonly --manual --preferred-challenges dns</syntaxhighlight> as root. This will generate a key pair on your workstation, for your domain. Replace asmith15.ops345.ca with the domain that's correct for you. The output below is cut off after the notice to publish the TXT record:


Create an alias to deliver emails meant for root to andrew instead:
[[File:AWSCertbot-part1.png|border|center]]


* Edit /etc/aliases (it's a text file).
Let's Encrypt verifies that you're authorized to get a certificate for yourusername.ops345.ca by asking you to add a TXT record under that domain. It's a reasonable assumption that if you have control over the DNS records for a domain: it's your domain.
* Uncomment the bottom line and change "mark" to your username.
 
* Run "newaliases".
* Leave the terminal running certbot and go to Bindistrar to add the TXT record Let's Encrypt asked for.
* Send an email to root@yourusername.ops345.ca and make sure it ends up in your user's Maildir
* To avoid mistakes getting cached: double-check your record, then test it in another terminal on your workstation:<syntaxhighlight lang="bash">dig _acme-challenge.asmith15.ops345.ca TXT</syntaxhighlight>
* If there is a mistake: note the TTL, it will make it hard for you to check that you fixed it correctly. But you can query the authoritative server for ops345.ca directly:<syntaxhighlight lang="bash">dig _acme-challenge.asmith15.ops345.ca TXT @littlesvr.ca</syntaxhighlight>
* Once it looks good to you: press Enter in the terminal running certbot:
 
[[File:AWSCertbot-part2.png|border|center]]
 
* If that looks good: you can delete the TXT record from your DNS, it was only needed for a single use.
* Save your private key and the certificate in your home directory to make them easier to find later and easier to back up:<syntaxhighlight lang="bash">mkdir -p ~yourusername/ops345/keys/certbot
cp /etc/letsencrypt/live/yourusername.ops345.ca/privkey.pem ~yourusername/ops345/keys/certbot/yourusername.ops345.ca.key.pem
cp /etc/letsencrypt/live/yourusername.ops345.ca/cert.pem ~yourusername/ops345/keys/certbot/yourusername.ops345.ca.cert.pem
chown -R yourusername ~yourusername/ops345/keys/certbot</syntaxhighlight>
 
The file yourusername.ops345.ca.cert.pem is what a CA would send you after you paid them. It:
* Is useless without its private key pair.
* Is not tied to the workstation you used to create it.
* Is not tied to any particular service (e.g. Apache).
* Is tied to the yourusername.ops345.ca domain.
* Will become useless after it expires.
 
== Set up Apache to use your new keys ==
 
Do this part of the lab on your www.yourusername.ops345.ca machine only. No need to touch the slaves you created in the assignment.
 
* Remember that your keys are tied to a domain, so make sure that the ServerName option in /etc/httpd/conf/httpd.conf is set to your full domain name yourusername.ops345.ca
* Apache can be configured to provide service over HTTPS relatively easily once you have the keys you need, but on Amazon Linux the SSL apache module is not installed by default, so install it now on your www server (give the machine a temporary elastic IP to allow yum to work, and release it after you're done):<syntaxhighlight lang="bash">yum install mod_ssl</syntaxhighlight>
* Both your private key and your certificate need to be on the server because Apache needs to use them both. Use scp to copy them from your workstation to the server, and then copy them into the directories commonly used for this purpose:
[[File:AWSCopyCertbotKeys.png|800px|border|center]]
* Configure Apache to use those keys by setting the following two parameters in /etc/httpd/conf.d/ssl.conf:<syntaxhighlight lang="ApacheConf">SSLCertificateFile /etc/pki/tls/certs/yourusername.ops345.ca.cert.pem
SSLCertificateKeyFile /etc/pki/tls/private/yourusername.ops345.ca.key.pem</syntaxhighlight>
* Restart apache and confirm that there are no errors in /var/log/httpd/error_log nor in /var/log/httpd/ssl_error_log
* Configure your firewalls and port forwarder to handle HTTPS, which works over TCP port 443:
** Add an iptables rule in the nat table on router.
** Add a rule for HTTPS in the router's security group to allow access from anywhere.
** Add a rule for HTTPS in www's security group to allow access from the router only.
* Test it in Firefox. It should work well for https://yourusername.ops345.ca and not well for https://www.yourusername.ops345.ca
[[File:AWSHTTPSWorks.png|800px|border|center]]
 
The problem with https://www.yourusername.ops345.ca is that your certificate is for a different domain. There are several different ways to deal with that, but we're not going to fix it.


= Submit evidence of your work =
= Submit evidence of your work =
Line 113: Line 127:
For this lab, please submit screenshots that show you've completed the work, unless your professor has given you different instructions. As a minimum that's:
For this lab, please submit screenshots that show you've completed the work, unless your professor has given you different instructions. As a minimum that's:


* Your email VM details in the AWS console.
* Firefox showing https://yourusername.ops345.ca, or better yet https://yourusername.ops345.ca/nextcloud/
* A dig query for your two new DNS records.
* The output of the mount command.
* The received emails in your Maildir.


[[Category:OPS345]]
[[Category:OPS345]]

Latest revision as of 14:10, 21 August 2023

Encryption, certificates, etc.

Encryption means converting plain text (something you can read/use, it doesn't need to be text) into cyphertext. The cyphertext created by a good encryption algorithm is impossible (or, for weak algorithms: at least impractical) to decrypt (covert back into plain text) without a key.

You've been using public key cryptography for your entire life (unless you were born before the 1990s). And you've been setting up public key cryptography for yourself since at least OPS245. If you actually understand how this stuff works: you'll be far ahead of the average sysadmin.

We don't have the time to do a comprehensive overview of cryptography, so I strongly encourage you to put the book Crypto by Steven Levy on your "must-read" list. Unfortunately they no longer have copies for check-out at the library, but I'm sure you can still find a way to read it. I have yet to see a better introduction to encryption. It's not a course reqirement - but if you don't want to be clueless about security fundamentals online - read that book and understand it. It reads like a novel, and it's perfectly readable even if you have no interest in math:

"crypto" by Steven Levy

In a nutshell, here are the most important points, the absolute minimum you need to be comfortable with this:

  • Public key encryption (also called assymetric encryption) uses two keys: a public key and a private key.
  • The two keys are permanently tied to each other by complex mathematics (read the book to get a feel for the fundamentals). You can't mix one public key with an unrelated private key.
  • The private key is like your password, you never give it to anyone. The public key is of no value to attackers, so there's no point in trying to protect it.
  • Anyone can encrypt something with the public key, but only the private key can be used to decrypt that.
  • Anyone can verify that a file signed using the private key has not been modified except by the owner of the private key.
  • A certificate is a public key typically signed by a third party's private key.
  • Symmetric encryption only has one private key, no public key. That makes it very hard to use with strangers on the internet.
  • Hashing is used a lot in cryptography, but it's not an encryption tool.

With those fundamentals you should be able to follow this diagram which describes how SSH key authentication works. The diagram is from Sébastien Saunier's blog (which is no longer online):

A diagram explaining how public / private keys work.

Certificate Authorities (CAs)

The problem with assymetric encryption is the distribution of public keys. The encryption strength is meaningless if the client can't be sure it has the unmodified public key for the server. That's where a third party gets involved. This third party is called a Certificate Authority.

The exact same concepts from the section above are used for CA-signed certificates. There's just a third party involved - which makes it seem like magic for too many people, including professionals in our field.

If you have any ambitions in this field: set a goal for yourself to understand this stuff fully. At least eventually, if not now.

Setup on the server

Let's take a web browser and web server for an example - since that's the most common use of this setup.

  1. First the web server administrator needs to generate a key pair, roughly the same as what you've been using for SSH (but using different commands).
  2. The server admin needs to have the public key from that pair signed by a CA which browsers will accept as reliable. There are many such CAs, you can look in your browser's settings to see a full list. Typically people choose the cheapest option that will work in their setup. That's around 60$ a year.
  3. The admin needs to pay the CA for the service. There's only one free option available which we'll use in this course.
  4. The CA will use their private key to sign the web server's public key. That will allow people who already have the CA's public key to verify that the web server's public key has not been modified (by anyone other than the people who have access to any trusted CAs private key).
  5. The server admin can download this signed public key (a.k.a. a certificate) from the CA.
  6. The server admin will configure the web server to use the server's private key and the CA-signed version of its pair public key for secure communication over HTTPS.
ServerCA.png

A certificate will always be linked to an FQDN. That mostly makes sense since web browsers connect to a web server using a domain name. Sometimes that's a pain in the neck for the administrator (you'll see why later) and the concept of "wildcard certificate" exists, but I was never able to set one up to work properly.

Client communicating with server

Now that the server is configured, let's look at what happens when a web browser connects to a web server using HTTPS.

  1. The web browser connects to a web server, expecting to establish encrypted communication.
  2. The web server will send to the client its CA-signed public key.
  3. The browser came installed with a list of trusted CAs' public keys. Good luck figuring out how this list was compiled by whom when and how it's kept up to date. Let's just assume for now that those are all trustworthy, since everyone else assumes the same. It uses the appropriate CA's public key from that list to verify the server's public key.
  4. At this point a combination of signing, encryption, and exchange of symmetrical encryption keys can be used to establish a connection where all traffic in both directions is encrypted.
BrowserCA.png

Self-signed certificates

Options exist if you need encrypted communication to your web or email server but you're not willing to pay for a CA or deal with the complexities required by Let's Encrypt:

  1. You can self-sign a certificate, and add that certificate directly into your client software. If you have full control over all your client software: this is more secure and reliable than using a typical CA.
  2. You can set up your own certificate authority (it takes one command to do that) to sign whatever certificates you want, and configure your client software to trust your CA. Again, this is more secure and reliable than relying on potentially untrustworthy CAs.

We won't be doing either of those techniques in this course because their application requires closer knowledge of the business where they're used, and therefore it's too specific for this course.

HTTPS for your web server

Generally-trusted CAs' services cost money. We're going to avoid extra costs in this course, and will use the one and only free CA which is trusted by a typical browser: Let's Encrypt.

Let's Encrypt won't give you a certificate for more than 3 months, which is why the paid-for CAs still exist. They encourage you to set up automatic renewals of your certificate using their custom software, which is not always doable or even desireable. But it's free and 3 months is good enough for us.

Create your signed certificate

The steps below follow relevant instructions from the Let's Encrypt Creating and Deploying a LetsEncrypt Certificate Manually page.

  • Install certbot in your workstation using apt or the Software Manager. This is a command-line-only application.
  • Run 
    certbot certonly --manual --preferred-challenges dns
    as root. This will generate a key pair on your workstation, for your domain. Replace asmith15.ops345.ca with the domain that's correct for you. The output below is cut off after the notice to publish the TXT record:
AWSCertbot-part1.png

Let's Encrypt verifies that you're authorized to get a certificate for yourusername.ops345.ca by asking you to add a TXT record under that domain. It's a reasonable assumption that if you have control over the DNS records for a domain: it's your domain.

  • Leave the terminal running certbot and go to Bindistrar to add the TXT record Let's Encrypt asked for.
  • To avoid mistakes getting cached: double-check your record, then test it in another terminal on your workstation:
    dig _acme-challenge.asmith15.ops345.ca TXT
  • If there is a mistake: note the TTL, it will make it hard for you to check that you fixed it correctly. But you can query the authoritative server for ops345.ca directly:
    dig _acme-challenge.asmith15.ops345.ca TXT @littlesvr.ca
  • Once it looks good to you: press Enter in the terminal running certbot:
AWSCertbot-part2.png
  • If that looks good: you can delete the TXT record from your DNS, it was only needed for a single use.
  • Save your private key and the certificate in your home directory to make them easier to find later and easier to back up:
    mkdir -p ~yourusername/ops345/keys/certbot
cp /etc/letsencrypt/live/yourusername.ops345.ca/privkey.pem ~yourusername/ops345/keys/certbot/yourusername.ops345.ca.key.pem
cp /etc/letsencrypt/live/yourusername.ops345.ca/cert.pem ~yourusername/ops345/keys/certbot/yourusername.ops345.ca.cert.pem
chown -R yourusername ~yourusername/ops345/keys/certbot

The file yourusername.ops345.ca.cert.pem is what a CA would send you after you paid them. It:

  • Is useless without its private key pair.
  • Is not tied to the workstation you used to create it.
  • Is not tied to any particular service (e.g. Apache).
  • Is tied to the yourusername.ops345.ca domain.
  • Will become useless after it expires.

Set up Apache to use your new keys

Do this part of the lab on your www.yourusername.ops345.ca machine only. No need to touch the slaves you created in the assignment.

  • Remember that your keys are tied to a domain, so make sure that the ServerName option in /etc/httpd/conf/httpd.conf is set to your full domain name yourusername.ops345.ca
  • Apache can be configured to provide service over HTTPS relatively easily once you have the keys you need, but on Amazon Linux the SSL apache module is not installed by default, so install it now on your www server (give the machine a temporary elastic IP to allow yum to work, and release it after you're done):
    yum install mod_ssl
  • Both your private key and your certificate need to be on the server because Apache needs to use them both. Use scp to copy them from your workstation to the server, and then copy them into the directories commonly used for this purpose:
AWSCopyCertbotKeys.png
  • Configure Apache to use those keys by setting the following two parameters in /etc/httpd/conf.d/ssl.conf:
    SSLCertificateFile /etc/pki/tls/certs/yourusername.ops345.ca.cert.pem
SSLCertificateKeyFile /etc/pki/tls/private/yourusername.ops345.ca.key.pem
  • Restart apache and confirm that there are no errors in /var/log/httpd/error_log nor in /var/log/httpd/ssl_error_log
  • Configure your firewalls and port forwarder to handle HTTPS, which works over TCP port 443:
    • Add an iptables rule in the nat table on router.
    • Add a rule for HTTPS in the router's security group to allow access from anywhere.
    • Add a rule for HTTPS in www's security group to allow access from the router only.
  • Test it in Firefox. It should work well for https://yourusername.ops345.ca and not well for https://www.yourusername.ops345.ca
AWSHTTPSWorks.png

The problem with https://www.yourusername.ops345.ca is that your certificate is for a different domain. There are several different ways to deal with that, but we're not going to fix it.

Submit evidence of your work

For this lab, please submit screenshots that show you've completed the work, unless your professor has given you different instructions. As a minimum that's:

Retrieved from "http://wiki.littlesvr.ca/w/index.php?title=OPS345_Lab_6&oldid=728"