Fast Secured AWS Deployment: Elastic Beanstalk, IAM and ELB for TLS (SSL) Serving
The latest trends on major sites is to serve content using HTTPS only. It actually offers several interesting advantages, like:
- Protection against Man-in-the-Middle Attacks, where someone is able to hear your connection and get sensitive information (e.g. cookies)
- Avoids (to some extent) some nasty Bots and Spiders
- Conveys more trust from Users, especially those who always ask “Where’s the Key Icon I’ve heard about on TV?” (e.g., your parents)
Some initial protocol nomenclature:
- HTTPS is the URL Scheme for Secure HTTP, which is HTTP over TLS/SSL
- SSL (Secure Sockets Layer) is an Application Protocol. As such, it is implemented as System Level Libraries (OpenSSL and Java contains a SSL Runtime). It is combined with the real protocol, and it is commonly used not only with HTTP, but also with the Simple Mail Transport Protocol (SMTP), Post Office Protocol 3 (POP3) and Internet Message Access Protocol (IMAP)
- TLS is an Evolution of SSL. Most likely, you’ll be dealing with TLS, even if people still call it SSL.
A bit about Cryptography
I love cryptography, but I’ll spare most of the details. TLS is part of the so-called “Public Key Infrastructure” (PKI), where there’s a Web of Trust among entities.
Every Browser/Platform/Operating System contains a set of “Root Certificates”, which identifies Real-Life Authorities Entitled to Sign and Recognize Other Public Key Certificates. A website you visit via HTTPS sends you its Certificate, and your browser tries to confirm it was signed by one of the Root Certificates and their partners. In the end, Certificates map to Public/Private Keys, which is used for encrypting the data between all the entities.
So basically, when you open a browser and see a Certificate Alert, most likely, it is due to signature. Common causes include:
- Expired Certificates
- Certificates issued from a Certification Authority (CA) which the System does not Trust. Most likely, the own Issuer Signed his own certificate (Self-Signed Certificate)
- Mismatched Domain Hostname (on the Certificate) against the URL
Understand that in TLS, you need at least one Certificate, which mostly means the server. However, the Client can also use a Certificate, and use it for identifying itself. There are also Certificates issued for Code Signing, especially for Mobile Apps, as well as email, and file signatures with legal validity.
[Security Configuration Vulnerabilities: Newvem scans, detects and highlights configurations that deviate from your policies and can present risks to your cloud deployments. Learn More]
A TLS Use Case
Serving TLS used to be a problem in the past decade, most likely due to the Heavy CPU Processing (it is actually not). Anyway, the hardest part, for most Administrators, is dealing with the workflow involved, which means, in real life:
- Issuing the Certificate (Public and Private Keys)
- Generating a Certificate Signing Request (CSR)
- Sending the CSR to a Certification Authority
The Certification Authority will validate your data and return you the Signed Public Certificate, as well as a (optionally) root certificates and a chain of trusted authorities (if the CA depends on another CA, it will be there). From that point, you install the Signed Certificate, the Private Key to the Certificate, as well as the optional chain.
SSL Certificates have a Major Limitation: The Certificate is checked from the start of the TLS Layer. As such, things like Hosting Multiple Domains won’t work: You’ll need one different IP for each HTTPS endpoint, and this makes more expensive from Hosting Providers.
TLS on Amazon Web Services Cloud
On Amazon Web Services, TLS is a First Class Citizen, via the Elastic Load Balancer (ELB) Service. As it is used by Elastic Beanstalk, this means that TLS is supported out of the box, via Amazon Identity and Access Management (IAM).
However, the process is a bit different: You’ll load your Certificate not on your Machines, but on your Load Balancer, and all existing instances will talk only HTTP. Which is a good thing, since it means less CPU power.
Once loaded, your certificate will have an Amazon Resource Name (ARN), and then your load balancer can make use of it.
Creating an Elastic Beanstalk Application
Actually, that part got easier: A few days ago, I’ve released a new Maven Archetype for Elastic Beanstalk Apps using my Maven Plugin, and it will work like a charm for our purposes. So, if you have Maven installed, just type:
$ mvn archetype:generate -Dfilter=elasticbeanstalk-service-webapp-archetype -DgroupId=com.newvem -DartifactId=newvem-tls-sample
Fill the details you want, and it will create a new Maven Application. Review the README.md for Instructions on Maven Setup (if needed), then compile / deploy it:
$ mvn –Pdeploy deploy
Once completed, the application will be ready for launching. Log on the AWS Console, under the “Elastic Beanstalk” section, and then select the application you just deployed, then click on “Launch New Environment”. Here are what you need to launch:
1 - Pick an available environment name and URL, and select “Container Type” to “32-bit Amazon Linux Running Tomcat 6”. Click on Continue.
2 - Fill the name of your Existing Key Pair. For the Application Health Check URL, pick “/services/api/v1/debug”, then click on Continue -
Wait a while while your application loads. Once it’s ready, http://<yourapp>.elasticbeanstalk.com/services/api/v1/debug will show you some JSON about the Header Data received.
Creating a Self-Signed Certificate and Importing into AWS Elastic Load Balancer
I will short-circuit the process a little, by creating a self-signed certificate. Other than that, the steps here outlined are the same described by the “Managing Server Certificates” section from the AWS Identity and Access Management User Guide:
1 - Install OpenSSL. Generate the RSA Key:
$ openssl genrsa 1024 > server.key
2 - Generate the Signing Request. Under “Common Name”, make sure it matches the name of your environment:
3 - Generate the self-signed Certificate:
4 - Install the AWS IAM CLI Tools here.
Unpack and unzip. Review the Instructions, but basically:
- Copy / Edit aws-credential.template to a new file, and write your AWS Access / Shared Keys. Save, then set your AWS_CREDENTIAL_FILE environment variable to the path of this new file
- Set the AWS_IAM_HOME environment to the path where you unpacked the IAM CLI Tools
- Make sure JAVA_HOME is set as well.
In order to test, just call iam-servercertlistbypath. It must show nothing, but it actually called AWS. In my case, however, it returns a few records:
Lets upload the certificate. I’ve used the hostname of the certificate as the ‘-s’ parameter. Make sure you change yours.
Copy down the Amazon Resource Name (“arn:aws:”) of the new certificate. In the example below, it is “arn:aws:iam::235368163414:server-certificate/newvem-tls-sample.elasticbeanstalk.com”, and the 12-digit sequence is my AWS Customer ID (shown in 3 sets of 4 digits separated by a Dash when I look into my AWS Account Usage, for instance).
Congratulations! You’ve created the certificate and uploaded it to AWS.
Now we need to switch to it: From your Elastic Beanstalk Application, set the ARN and enable the HTTPS Listener Port to 8443, then click on “Apply Changes”
Reopen the page, now with HTTPS. Your browser is likely to show you a warning, since we’ve actually used a self-signed certificate. Proceed. Here are my results:
About Those Extra Headers
Actually, if you notice, you’ll have those “X-Forwarded” headers (the Jersey Handler turns to lowercase). They mention the port and protocol used, as well as the hostname and Elastic Beanstalk Instance used. Of particular concern, the “X-Forwarded-Host” is useful if you happen to use a wildcard certificate and your architecture needs to figure out which domain was called.
Actually, you might not even need a wildcard. Some Certificate Vendors (namecheap, for instance), actually create the certificate with double common names, thus enabling you to serve both www.example.com as well as example.com.
If you want to see the Remote Address, there’s a catch: They are also Extra Headers, but in case of the Tomcat/Java Containers for Elastic Beanstalk, it contains extra configuration (Valves, as they’re called), so they’re seen as the usual ServletRequest.getRemoteAddr() value. If you are porting from another other load balancer/architecture and you’re considering to switch, mind that change.
You could test by calling http://yourapp.elasticbeanstalk.com/services/api/v1/remote, and it will show your remote address.
[Newvem scans and identifies the status of your security group configurations, continuously monitors their status, and alerts you of vulnerabilities. Learn More about Newvem]
Bonus Track: Java Applications
A common case, when you’re using Java, is to recognize / import Public Certificates without the proper trust relationships. How to do it?
Two steps:
1 - Export the Certificate, by opening a connection to the server to acknowledge. OpenSSL contains a custom client to do this:
Hit ^C, then copy / paste the “—-BEGIN CERTIFICATE—-“ and “—-END CERTIFICATE—-“ sections into a new file called “certificate.pem”. Save it.
2 - Use keytool to import it.
This way, your Java Clients are able to accept the certificate.
A couple of tips, Java related:
- Default Java Certificates are held into the your jre/lib/cacerts file, and the default password is ‘changeit’
- I strongly recommend KeyStore Explorer for managing your cacerts file.
One Last Advice
Prior to submitting your CSR request, make sure you are able to follow your provider instructions. In the examples above, I’ve used OpenSSL, but keytool is fine as well, and they’re likely to be responsive to your needs.
Closing and Moving Forward
In this article, we’ve covered the general steps in endpoint security using TLS on your AWS Elastic Beanstalk Applications. It is not meant to be a full tutorial, of course. For those, we recommend you to read Bruce Schneiers’ “Applied Cryptography” from if you want to understand the theory in detail.
HTTPS clients are a reality, and more and more services are going to use it. I see that as a good thing, although I with people could use more Client Certificates. Regardless of that, I hope SSL becomes not a problem, but a feature in your future AWS Elastic Beanstalk Applications.
Thank you!
[Newvem analytics tracks you AWS cloud utilization:
- Hourly Utilization Pattern Analysis
- Reserved Instances Decision Tool
- Resource Resizing Opportunities
Get Started with Newvem for Free or Learn more about Newvem]
About the Author
Aldrin Leal, Cloud Architect and Partner at ingenieux Aldrin Leal works as an Architect and QA Consultant, specially for Cloud and Big Data cases. Besides his share of years worth between the trenches in projects ranging from Telecom, Aerospatial, Government and Mining Segments, he is also fond with a passion to meet new paradigms and figure a way to bring them into new and existing endeavours.
Keywords: Amazon web services, Amazon AWS console, Amazon Cloud Services, Security, TLS, SSL, Certificate, POP3, ELB, Elastic Load Balancer, Elastic Beanstalk, IAM, Cryptography, Open SSL,
You must be logged in to post a comment.