What are Server Certificates?
Server certificates are an extremely recurrent piece of software that the average network user has no knowledge of but encounters every time the user accesses the internet. To any person within the technology industry, they are known as a method of confirming the identity of a server to a client.
Types of Server Certificates
The two most common types of server certificates are a web server certificate, and a RADIUS server certificate. Both server certificate types will be explored in more detail, but the common thread between them is how they identify the involved parties with a certificate chain of trust.
To establish trust, server certificates should always be issued from a Certificate Authority (CA) that can be recognized by every client device. The reason is because operating systems and web browsers have certificate stores. These come with a set of trusted certificate authorities by default, which are known as public certificate authorities. If your server certificate is signed by a public CA, then the client devices would not see any SSL errors if the server certificate is correctly used.
You can use server certificates signed by private certificate authorities, but you need to go through additional steps as an administrator to make every single device trust the issuing private CA to prevent users from seeing SSL errors or warnings. Some operating systems are not friendly as well. For example, iOS would show a warning if you try installing a private certificate (certificate that is not recognized by default by iOS).
Web Server Certificate
A web server certificate binds to a particular web server and activates the HTTPS protocol to protect communications between the client and the web server. For those unaware, a website URL is preceded by a transfer protocol, either HTTP or HTTPS. HTTPS means that the communications with this web server are secure, and it is a fast growing trend to include a server certificate among popular websites.
To use a server certificate on a web server, the Subject Alternative Name (SAN)/Domain Name System (DNS) should match the Fully Qualified Domain Name (FQDN) of the web server. Or at least it should be a wildcard entry, which is a public key certificate that can be used with several subdomains of a website domain.
Establishing Web Server Certificate Trust
For a web server to establish trust with a client, they must perform a handshake, which can be simplified into three main steps. First, the client and server send a hello message that contains information to establish the client’s communication preference (basically the format in which they will communicate).
Next, the server presents the web server certificate to prove its identity. The web server certificate is identified based on its SAN and the client deciphers whether the certificate has been issued from a trusted CA.
If the certificate is trusted, the client moves on to the final key exchange. The encrypted message is exchanged based on the symmetric algorithm established in the hello message. Both the client and server agree to use a key to decrypt the encrypted messages and communicate securely while the web server is in use. This process occurs faster than a human can detect, but ensures that all communications will only be read by the server and client.
An interesting use case involves the process of equipping Windows servers with web server certificates. In order to provision a Windows web server with a certificate, the server account Web Hosting must have a server certificate with Common Name (CN) that matches the URL hosted by the server. This is often used with Internet Information Service (IIS) and presents a unique method of establishing trust between client and server.
RADIUS Server Certificate
A RADIUS server certificate is used to prove that the RADIUS server a client is authenticating to is in fact the correct server. Based on the CN on the certificate, the end user can feel secure knowing that they will not fall victim to a Man-In-The-Middle attack.
Establishing RADIUS Server Certificate Trust
The process of confirming the identity of a RADIUS is called server certificate validation. When a user connects an EAP secured network, a TLS handshake will be initiated (this is similar in concept to the web server certificate handshake).
EAP Authentication with Server Certificate Validation
When using an EAP authentication method, an encrypted EAP tunnel is created to prevent anyone but the client and server from viewing the messages being exchanged. Within the EAP tunnel, a certificate chain of trust is between the server certificate, an intermediate certificate, and the client. Trust is established by validating the server with the help of Root CA and the CN of the server certificate. Then both parties can communicate securely. While it is a best practice to include the intermediate certificate in the chain, the process can be completed with just the root certificate. Because clients use Root CA and name to validate the server. Whereas servers show the missing piece, Intermediate CA, to complete the certificate chain and prove their identity in the process.
Device Authentication and Server Certificates
After trust is established, the user can then send over their certificate or credentials (based on the authentication type). The unique thing about RADIUS authentication is that it’s purely account based, meaning just about any device can be authenticated securely. If the device can be equipped with a certificate, it can be authenticated by the RADIUS with EAP-TLS. It can even be configured to authenticate based on a Mac Address, which is especially useful for IoT devices that cannot be loaded with a certificate.
During the authentication process, the device proves its identity as a trusted network user, but the RADIUS server must also prove its identity. Without server certificate validation, the user could fall victim to a Man-in-the-Middle (MITM) attack. During the TLS handshake, the RADIUS provides its server certificate to prove that it is the trusted server the user is meant to authenticate to.
Distributing Server Certificates
SecureW2 provides the tools to easily and quickly create a server certificate for any organization. Our solutions are vendor-neutral and can be easily integrated with any network infrastructure.
To create a server certificate in SecureW2’s management portal, you first enter settings for the OS type, the admin user who is approved to create the certificate, and confirm the correct Mac Address. Then they must enter the common name to be used to identify the certificate, and indicate the intended use of the certificate. In the example below, both options of server and client authentication were chosen.
Server Certificate Applications
Server certificates are just one of many possible use cases for the certificates. Beyond server identification, they can be used for VPN authentication, email security, Smart Card security, managed device authentication, and much more.
But when used for web servers and RADIUS, these certificates are used constantly to ensure that everyone is able to connect securely and browse online without worrying about bad actors interfering. SecureW2’s certificate solutions are known for usability and strength of security; check out our pricing page to see if our affordable certificates could be key for your organization.
*** This is a Security Bloggers Network syndicated blog from SecureW2 authored by Jake Ludin. Read the original post at: https://www.securew2.com/blog/a-guide-to-server-certificates/