If you think Certs are a circular shaped candy that comes in a roll; then this blog is probably not for you. The question should not be whether we are talking about the minty kind or the fruity kind. However, if you are asking yourself whether we are talking about SAN certs or wildcard certs you are on the right track: keep reading. Webopeida.com defines digital certificate as follows:
An attachment to an electronic message used for security purposes. The most common use of a digital certificate is to verify that a user sending a message is who he or she claims to be, and to provide the receiver with the means to encode a reply.
Essentially a digital cert provides a method of proving some electronic information. The x.509 standard exists to provide a Public Key Infrastructure (PKI) to manage the digital certificates necessary for certain electronic communications. One can use digital certificates while navigating through the web (browsing a secure web server), creating encrypted connections (to your work’s private network), or even to establish a secure wireless connection without fear of digital eavesdropping. The key function of the digital cert is to encrypt data so that it is secure until reaching the approved party(s). At which time the data is decrypted for viewing.
Let’s focus on Secure Sockets Layer (SSL) certificates. When a user types in https:// that user is attempting to create a secure connection to a web server. SSL is based on another protocol TLS or Transport Layer Security that is most commonly used today when you need a very secure wireless connection. When invoking SSL/TLS asymmetric encryption is used. Asymmetric encryption uses different keys for encoding and decoding electronic messages. To encrypt the message a public key, known by both parties is used to encrypt the data. A private key is generated and it is used to decrypt the data. Using the keys in concert digitally signs the communication.
How does this happen? Well when the administrator who set up the web server to be secure set out on this task, they created a file called a Certificate Signing Request (CSR). This file contains the public key along with key information regarding the server in question such as domain name and purpose of the certificate: in this case an SSL certificate. The administrator now sends the request to a public Certificate Authority (CA) such as DigiCert or VeriSign. This CA then verifies the administrator’s identity and that you have rights to the domain that you are requesting secure communications. Depending on the public CA selected and how they handle your request, they will send you either a single CA cert or a file with a chain of authority containing the root cert and intermediate cert. If this is a well-known CA then your browser already has the CA certificate in its trusted root store of root certificates. If not users need to import this certificate for the browser to connect you securely.
And why are we going through all this? Well for one you do not want your information floating around the Internet in clear text. You could also be exposing yourself to a man-in-the-middle (MITM) attack. This explains why your browser sometimes complains about connecting to a secure web page. If your browser examines the information in the cert and does not trust the information presented, it gives you an option to break the communications before actually connected or choose to continue at your own risk. The browser is presented with the certificate’s key info…
CERTIFICATE INFO
- Version
- Serial number
- Signature algorithm ID
- Issuer’s name
- Validity period
- Subject’s name
- Subject’s public key
- Extensions
Your browser also has a certificate revocation list (CRL) which flags certificates that are no longer valid even though their validity period is current. When a certificate becomes invalid prior to the end of its validity period the CRL affords a method of revocation. There are a few reason for this. It could be that the certificate is not being used in the intended manner or that the private key has been compromised. There is also a protocol that proactively checks to see recently revoked certificates. Online Certificate Status Protocol (OCSP) is invoked for connections that need to be extremely secure. During the setup of the connection the authenticator checks in to a OCSP server to make sure that certificates that have been revoked but not propagated to all the CRLs are flagged.
So as you can see a lot goes on in the background when you access a secure server. Thankfully very smart engineers came up with this strategy which (for now) is keeping us safe!
Author Bio: John Busso is a Senior Network Engineer/Mobility Specialist at CCSI. He has almost 20 years experience providing secure voice and data solutions. John has been a Subject Matter Expert for Enterprise Mobile Solutions such as Guest WiFi and BYOD, providing vision for diverse clients.
His experiences include advanced requirements-gathering, architecture, consulting, proof-of-concept and integration of complex systems; advanced knowledge of integrating secure enterprise mobile systems; advanced enterprise-wide architecture, analysis, optimization and remediation of wired and wireless systems; architecture of complex management solutions; advanced implementation of leading-edge wireless voice, security and asset optimization solutions.
John has been an Adjunct Professor and trainer. He holds numerous Industry certifications, including CISSP CWNP, CCNP, ACMP and ITIL. His experience includes working with retail, TNL-Couriers, DC’s and Airports, Healthcare, Education, DOD, Local Government, Financial, Non-Profit-Public WiFi, Entertainment and Hospitality industries. His expertise is in mobility, security, WLAN, WAN, LAN, VoWiFi, RFID, RTLS, WIPS, WIDS, DAS, licensed/unlicensed PTP and PTMP networks.
