 Hi everyone, welcome to this session. My name is Farah Juma and I'm a software engineer at Red Hat working on security for the WildFly application server. So today we're going to be talking all about the ACME protocol, which is a protocol that greatly simplifies certificate management. So in particular, we're first going to go over traditional certificate management to understand the need for the ACME protocol. Then we'll dive right into what the ACME protocol is and how it works. And then finally we'll go through a demo so you can see how the ACME protocol has made it possible to very easily obtain signed certificates for WildFly. So before we talk about traditional certificate management, it's important to understand the difference between self-signed and signed certificates. So first, just as a reminder, the TLS protocol allows communication between a client and a server to be encrypted. Now one of the things that occurs during a TLS handshake is that the client authenticates the server's identity by verifying the server's certificate. So the client checks to see if it trusts the issuer of the server's certificate. So a self-signed certificate is one that's been signed by the owner of the certificate. So in this example, this certificate has been issued to example.org and it's also been issued by example.org. So this certificate is self-signed. Now the use of self-signed certificates is generally considered to be bad practice since this bypasses validation from a trusted third party that's meant to ensure that the owner of a certificate is really who they say they are. Now when a server's certificate is self-signed, browsers present a warning requiring end users to manually confirm whether or not to accept the server's certificate. So I'm sure you've all seen this warning message before. Now a signed certificate, on the other hand, is one that's been issued by a trusted third party called the certificate authority. So this certificate authority ensures that the owner of a certificate is really who they say they are. So in this example, this certificate has been issued to devconf.info and it's been issued by let's encrypt. So when we access devconf.info from a browser, we'll see this little lock symbol here and the connection is secure message. So that's because our browser trusts let's encrypt, which is the issuer of this certificate, because that's a well-known certificate authority. So now that we understand the basics of signed certificates, let's take a closer look at what traditional certificate management actually entails. So let's say that we have a web server that's hosting a website called example.org. So when this web server receives an HTTPS request, it needs to present a signed certificate. So typically a server administrator is responsible for obtaining a signed certificate from a certificate authority and for configuring the server to make use of that certificate. So let's take a look at the steps that are involved for this. So the very first step is for the server administrator to create a certificate signing request that specifies the domain name that she wants to obtain a certificate for. So in this example, that would be example.org. Next, she would submit the certificate signing request to a certificate authority of her choice. She would then be responsible for proving ownership of example.org. Now once the certificate authority has issued a signed certificate, the administrator would then need to obtain the signed certificate from the certificate authority. She would then need to update the web server's key store to actually make use of this signed certificate. So then when the web server receives an HTTPS request, it will be able to present this newly obtained signed certificate. Now a certificate signed by a certificate authority is only valid for a certain period of time. After this point, the certificate expires requiring the owner of the certificate to obtain a new one. So the administrator would need to keep track of the expiry date and she would need to make sure that she repeats this whole process before the certificate expires. So as you can see, the number of steps required for traditional certificate management makes this a time-consuming and often complex task for server administrators. It's also very easy to forget to renew a certificate before it expires. So these issues led to the creation of the ACME protocol, which provides a way to greatly simplify the process of obtaining and managing signed certificates. So what is the ACME protocol? Well if you're familiar with American cartoons, when you think of ACME, you might be thinking of Wiley Coyote and his various schemes, but that of course is not what we're referring to here. So we're actually referring to the Automated Certificate Management Environment protocol, which makes it possible to obtain certificates from a certificate authority instantaneously without any human intervention. So this protocol was developed and is used by Let's Encrypt, which is a free open-source certificate authority. And this protocol actually became a standard back in March of 2019. So there are two key parts to the ACME protocol. There's an ACME client and an ACME server. An ACME server is a certificate authority that's capable of issuing signed certificates automatically. So Let's Encrypt is an example of an ACME server. An ACME client typically runs on a web server, and it proves to the ACME server that the web server really does control the domain name that it wants to obtain a certificate for. So in this example, the ACME client would be responsible for proving that the web server really does control example.org. So once this has been proven, the ACME client can then request, renew, and revoke certificates. And in case you're wondering, the ACME client communicates with the ACME server using JSON messages that are sent over HTTPS. So the ACME server is responsible for issuing challenges to the ACME client to validate domain ownership. So we're going to take a closer look now at how the ACME protocol works. So the very first step is for the ACME client to create an account with the ACME server. So to do this, the ACME client first generates a key pair, and then it sends an account creation request to the ACME server. So this account creation request is going to include the generated public key, and it's going to be signed using the generated private key. So this private key will actually be used to sign all of the ACME client's requests. So this is how an ACME server identifies an ACME client. Now this account creation request can also optionally include contact information. So email addresses, for example, that can be used to notify an administrator if there are any issues with this account. Now note that this account creation step only needs to be done once. So once an ACME client has created an account with the ACME server, it's ready to start performing certificate management actions. So let's take a look at how an ACME client can request a signed certificate from an ACME server. So the first step is to send a request to the ACME server that indicates the domain name that the ACME client would like to obtain a certificate for. So in this example, it's example.org. Next, the ACME server will respond to this request by providing the client with some challenges to prove that the web server really does control example.org. So as an example, an ACME server might ask an ACME client to provision an HTTP resource with specific content at a specific location or it might ask it to provision a DNS record with specific content. The ACME client just needs to respond to one of these challenges in order to prove ownership of the domain name. So in our example, our ACME client provisions an HTTP resource with the content that was specified by the ACME server and then it lets the ACME server know that it can go ahead and try to access this resource. The ACME server then issues a GET request for this HTTP resource and it verifies that the response contains the expected content. So if it does, then the ACME server knows that the web server really does control example.org. So once an ACME client has successfully proven ownership of the domain name, it then generates a key pair, generates a certificate signing request using the key pair and it sends the certificate signing request to the ACME server. So again, this whole request is signed using the ACME client's account private key. So the ACME server will then verify the signatures and if everything looks good, it will go ahead and issue the signed certificate which the ACME client can then download. Now remember that signed certificates are only valid for a certain period of time. So when it's time to renew the certificate, the exact same process that we just saw for requesting a certificate can also be used to renew the certificate. So what this means is that the entire certificate management process can actually be fully automated. So an ACME client can be used to both request and renew certificates. So this whole process is automatic and it doesn't require any human intervention. So this is obviously much simpler than traditional certificate management. So now that we understand how the ACME protocol works, you're probably wondering about what kinds of ACME server and client implementations are available. So on the server side, Let's Encrypt is the most well-known certificate authority that implements the ACME protocol. ACME pass go is another example. So the goal is for more certificate authorities to implement the ACME protocol in order to simplify certificate management. On the client side, there are many ACME client implementations out there written in many different programming languages. So the goal is to have ACME clients integrated directly into web servers so that server administrators don't need to worry about things like which ACME client to use or how to install it or things like that. Having it integrated directly just simplifies things even further. So when the ACME protocol was created, we developed a Java ACME client SPI that's part of the WildFly Electron project. So WildFly Electron is a set of Java APIs and SPIs for application server security. And Electron is the security framework that's used by the WildFly application server. So we actually integrated our Java ACME client SPI directly into WildFly, making it possible to obtain and manage certificates from any certificate authority that implements the ACME protocol using some simple CLI commands. Now it's important to note that our Java ACME client SPI could also be integrated in other web server environments as well. So we're going to take a look now at how we can very easily obtain a certificate from Let's Encrypt for WildFly. So I've set up a publicly accessible WildFly server instance and I've deployed a very simple web application. So if we take a look at our application, we'll see that we see that warning message that we saw earlier. So that's because my WildFly server instance is currently using a self-signed certificate. So we're going to take a look now at how to easily switch to using a certificate from Let's Encrypt. So we're going to switch over to our WildFly CLI so that we can configure our server instance. So the very first thing that we're going to do is configure a Let's Encrypt account. So we're going to create a certificate authority account resource and we're going to call it my Let's Encrypt account. Next, we're going to specify the key store and the alias that we want to use to store the account key that's going to be generated automatically for us. And then we can also specify an email address that Let's Encrypt could use to notify us if there are any issues with our account. Now, by default, this command is going to assume that I want to use the Let's Encrypt certificate authority. It is possible though to configure additional certificate authorities that implement the ACME protocol. And then you can specify which one you want to use here by also adding a certificate authority parameter. So for this example, we just want to use Let's Encrypt. So I'm going to go ahead and hit Enter. So now that we've configured our Let's Encrypt account, we're ready to start obtaining certificates. So to obtain a certificate from Let's Encrypt, I'm going to use the obtain certificate operation. So again, we're going to specify the key store and the alias that we want to use to store the certificate that we're about to obtain. Next, we specify the domain name that we want to obtain a certificate for. So this is the domain name for our wildfly server instance. Next, we specify the certificate authority account that we want to use to obtain this certificate. So we're going to use the My Let's Encrypt account, which we just configured. Finally, we're going to agree to Let's Encrypt's terms of service. So we just need to do this the very first time that we obtain a certificate from Let's Encrypt. So I'm going to go ahead and hit Enter and you'll see that this command succeeded. So what this command has done is it has sent a request to Let's Encrypt for a certificate with this domain name for our wildfly server instance. It's also automatically proven ownership of this domain name for us. It's then obtained the certificate from Let's Encrypt and it's stored it in our server's key store. Now I've already configured one way SSL for my server instance. So to make sure that we actually make use of this newly obtained certificate, we just need to reinitialize our key manager. So I'm going to go ahead and do that. So now if we switch back to our wildfly server instance and if we refresh the page, we'll see that the lock symbol now appears here with the connection is secure message. So if we inspect our certificate, we can see that it's been issued to the domain name that we specified. And we can also see that it's been issued by Let's Encrypt. Down here we can see the validity information. So certificates issued by Let's Encrypt are valid for 90 days and they recommend renewing them every 60 days. So because the process for renewing a certificate is exactly the same as the process for obtaining a certificate, we can easily automate the renewal process. So in particular, we can create a CLI script that checks if our server certificate is due to expire in the next 30 days. If so, we can simply execute the obtained certificate operation that we just used to obtain a new certificate for our server instance. And then to make sure that we actually make use of this newly obtained certificate, we can simply reinitialize our key manager. So we could create a cron job that runs this script, you know, twice daily, and then we never have to worry about our server certificate ever again. Our Wildfly server instance will always have a valid certificate signed by Let's Encrypt and it will always be up to date. So we just saw how easy it is to obtain a certificate from Let's Encrypt for Wildfly. Now remember that any certificate authority that implements the ACME protocol could be used here instead. Now one thing to keep in mind is that we also have a wrapper command that walks you through the process of configuring your certificate authority account, obtaining your certificate and also configuring one way or two way SSL. Now if you want more details on the ACME client, on our ACME client SPI or any of the Wildfly CLI commands that we just showed, be sure to check out our Wildfly Elitron blog. So today we learned all about the automated certificate management environment protocol, which allows signed certificates to be obtained instantaneously without any human intervention. And we saw how this protocol has made it possible to very easily obtain signed certificates for Wildfly. The key takeaway to keep in mind is that you never need to worry about forgetting to renew your server certificate ever again. Just use an ACME client and you'll be good to go. Thanks. Any questions?