Home > Support > FAQ
FAQ will help you quickly understand products and process.
With increasing demand and awareness of various types of online security issues, SSL/TLS encryption is always at the forefront. TLS/SSL certificate is now an essential part of any successful online business, but it can be a little overwhelming at times. Don't worry, our expert has put together with a helpful Q&A to help you understand the fundamentals of SSL certificates.
Click on the sectors below, or search any (input key words) that interests you.
*.PFX or *.P12 - Personal Information Exchange Format Supports storage of private and public keys and all certificates in the path. *If you wish to export a certificate and retain full private key functionality you must use the *.PFX or *.P12 extension*. *.CER or *.CRT - Base64-encoded or DER-encoded binary X.509 Certificate Storage of a single certificate. This format does not support storage of private keys. *.CRL - Certificate Revocation List Designates a certificate that has been revoked. *.CSR - Certificate Signing Request This file type is issued by applications to submit requests to a Certification Authority or CA. *.DER - DER-encoded binary X.509 Certificate Storage of a single certificate. This format does not support storage of private keys. *.P7B or *.P7R or *.SPC - Cryptographic Message Syntax Standard Supports storage of all certificates in path and does not store private keys. For technical articles from Microsoft about managing certificates on Windows Servers, check out: https://technet.microsoft.com/en-us/library/cc772898(WS.10).aspx
The application of OV and EV SSL certificate not only needs to verify the ownership of the domain name, but also needs to verify the real identity of the enterprise or organization. Moreover, applying for an enterprise-type OV or EV certificate needs to be reviewed manually, which makes it difficult for criminals to obtain such certificates. Please ensure that the information submitted is valid.
Before you can order an SSL certificate, it is recommended that you generate a Certificate Signing Request (CSR) from your server or device. Learn more about SSL certificates » A CSR is an encoded file that provides you with a standardized way to send CA your public key as well as some information that identifies your company and domain name. When you generate a CSR, most server software asks for the following information: common name (e.g., www.example.com), organization name and location (country, state/province, city/town), key type (typically RSA), and key size (2048-bit minimum). If you aren't sure of the exact company name or location when you generate the CSR, don't worry; we can change and finalize that information during our review process before we issue the certificate. Once your CSR is created, you'll need to copy and paste it into the online order form when you go to purchase your SSL certificate.
CT Logs are a publicly auditable record of TLS/SSL certificate issuance by each Certificate Authority. DigiCert was the first CA to build a CT log that was accepted by Google in 2013.
What are Site Seals or Trust Marks? Site Seals, also known as Trust Marks, are images that can be placed on a website to convey that the site is secure. These marks usually display the logo of the trust authority, often a technology security company, that provides the security validation. Site seals can be static or animated and may incorporate a "splash" or "information" page with details about the validated organization. Examples of site seals are the DigiCert Smart Seal, Norton Secured Seal, and Better Business Bureau's Business Accredited Seal.
TLS/SSL Certificate Validity Periods are currently 398 days, or about 13 months. They were recently reduced by the CA/B Forum starting Sept. 1, 2020 in response to Apple’s announcement stating they would not accept certificates for two-year validity periods. DigiCert has instituted a 397-day validity period in order to account for time zone differences.
Internet users can look beyond the lock by clicking on the padlock icon in the browser URL. Once clicked on, a pop-up box will appear with another option to “Show Certificate” in Safari, click on “Certificate” and details in Google Chrome, and click on the arrow and “More Information” in Firefox. By viewing the details of a TLS/SSL certificate you can verify the domain owner’s identity or organization to ensure you’re visiting an authentic website. View a step-by-step video here: https://youtu.be/BhMb6xgnFao
A Wildcard SSL Certificate is a single certificate with a wildcard character (*) in the domain name field. This allows the certificate to secure a single domain and multiple subdomains. For example, a Wildcard SSL Certificate for *.example.com, could be used for www.example.com, mail.example.com, store.example.com, in addition to any other subdomain name.
An Extended Validation (EV) Certificate is a type of TLS/SSL certificate that verifies that the certificate holder has undergone the most extensive level of vetting and identity background checks to certify that their website is authentic and legitimate. EV certificates are often required for high-profile brands, banks and other Fortune 500 companies. Extended validation means the certificate recipient and their website have completed a 16-point check to verify details such as: website domain, website owner, and the applicant’s legal, physical, and operational existence and identity.ck and blocklist checks.
A digital certificate authenticates the online credentials and identity of a person or organization and allows web users and recipients to know that the data they’re inputting is going to a trusted source. They are akin to security badges for websites and users and help keep the internet safe. Digital certificates are issued by Certificate Authorities (CAs) and are used to encrypt data online. Digital certificates are also known as public key certificates or identity certificates.
SSL (Secure Sockets Layer) and its successor, TLS (Transport Layer Security), are protocols for establishing authenticated and encrypted machine-to-machine communications (i.e., servers on a network, laptops to webpages, mobile phones messaging each other, etc.). SSL certificates are made up of a key pair: a public and private key, which work together to establish an encrypted connection. The certificate also contains the subject name, which is the identity of the certificate/website owner.
Post-Quantum Cryptography (also called quantum encryption or quantum-safe encryption) is a term to describe the developing cryptographic algorithms that will use quantum computers to encrypt machine-to-machine communication.
Elliptic Curve Cryptography (ECC) relies on the algebraic structure of elliptic curves over finite fields. It is assumed that discovering the discrete logarithm of a random elliptic curve element in connection to a publicly known base point is impractical.
Public Key Cryptography (asymmetric) uses encryption algorithms such as RSA and Elliptic Curve Cryptography (ECC) to create the public and private keys. These algorithms are based on the intractability of certain mathematical problems. Problems that can be solved in theory (e.g., given infinite time), but which in practice take too long for their solutions to be useful are known as intractable problems. With asymmetric encryption it is computationally easy to generate public and private keys, encrypt messages with the public key, and decrypt messages with the private key. However, it is extremely difficult (or impossible) for anyone to derive the private key based only on the public key.
Code signing is the process of applying a digital signature to a software binary or file. This digital signature validates the identity of the software author or publisher and verifies that the file has not been altered or tampered with since it was signed. Code signing is an indicator to the software recipient that the code can be trusted, and it plays a pivotal role in combating malicious attempts to compromise systems or data. Use cases for code signing include software for internal or external use, patches or fixes, testing, IoT device product development, computing environments, and mobile apps. Apart from code and software, code signing also applies to applications, firmware, files, messages, XML, scripts, containers, and images.
For public trust usage, code signing certificates are available as Organization Validation (OV) or Standard Certificate and Extended Validation (EV) Certificates.
Code Signing Certificates are generally used by software engineers or developers to digitally sign applications, drivers, software and other executables. They provide a way for end-users to verify that the code being issued has not been altered or compromised by a third party. Code Signing Certificates include your signature, your company’s name and, if desired, a timestamp.
What is S/MIME? Secure/Multipurpose Internet Mail Extensions, or S/MIME, is an internet standard to digitally sign and encrypt email messages. It ensures the integrity of email messages remains intact while being received.
Client Certificates are digital certificates that identify and validate individual email senders. They are also known as Personal ID certificates, but the technical name for them is S/MIME certificates. Client certificates allow organizations to authorize or block access to apps, websites, databases and devices. They also allow individuals to sign and encrypt messages they send and receive.
A Certificate Authority (CA) is a company or entity that has been authorized by browsers to issue TLS/SSL and other forms of certificates. These organizations undergo annual audits by third parties to ensure that they are following defined policies and procedures for validation, issuance, and revocation of certificates as laid out in the Baseline Requirements set forth by the CA/B Forum. Internet users who visit web pages not secured by CA-issued certificates will receive browser security warnings.
RSA stands for Ron Rivest, Adi Shamir, and Leonard Adleman— the men who first publicly described the algorithm in 1977. RSA Cryptography is based on the presumed difficulty of factoring large integers (integer factorization). Full decryption of an RSA ciphertext is thought to be infeasible on the assumption that no efficient algorithm exists for integer factorization.
The Certification Authority/Browser (CA/B) Forum is a voluntary group of certificate authorities (CAs), vendors of internet browser software, and suppliers of other applications that use X.509 digital certificates for TLS/SSL and code signing. Since its creation in 2005, the Forum has defined standards for the CA industry based on industry best practices. These standards, called Baseline Requirements, are a set of technical and procedural policies that must be adhered to by all public CAs, whether they are or are not members of the Forum. These standards improve the ways that TLS certificates are used, benefiting users of the internet and securing their communications.
Symmetric-key cryptography - Both sender and receiver share a single key and the sender uses this key to encrypt plaintext. The cipher text is sent to the receiver, and the receiver can apply this same key to decrypt the message and recover the plain text from the sender. Public-key or asymmetric cryptography –In public key cryptography (PKI), also known as asymmetric cryptography, there are two related keys called the public and private key. While the public key may be freely distributed, the paired private key must remain confidential. The public key is used for encryption and the private key is used for decryption.
Public Key Cryptography, also known as asymmetric cryptography, uses an asymmetric algorithm to generate a pair of keys (a public and private key pair) for the purpose of encrypting and decrypting messages. Public key cryptography varies from symmetric encryption which uses one key to encrypt and decrypt. Examples of public key cryptography, or asymmetric algorithms, include: RSA, elliptic curve cryptographic systems (ECC) and Diffie-Hellman.
SSL Cryptography uses Public Key Cryptography which requires asymmetric keys to encrypt and decrypt data sent between a server and a client—typically a website and a browser, or a mail server and a mail client, like Microsoft Outlook. The history of SSL, or Secure Sockets Layer, is closely intertwined with the history of the internet. In fact, the first viable version of SSL was released as SSL 2.0 in 1995 by the internet browser Netscape and upgraded to SSL 3.0 in 1999 before being deprecated due to several vulnerabilities. Then it was replaced by TLS, or Transport Layer Security, which is now considered a more secure version of SSL. However, many people still refer to TLS (the current internet security protocol in use) as SSL, and often the terms are used interchangably. Learn more about the Evolution of TLS/SSL cryptography here. TLS/SSL cryptography and encryption is most widely used to secure websites across the internet and is the reason you see HTTPS in your browser address bar. TLS/SSL encrpytion also secures sensitive information such as credit card numbers, social security numbers, and login credentials while in transit. To establish this connection, the browser and the server need a digital certificate, also known as a TLS/SSL certificate. The technology at work behind the scenes of TLS/SSL encryption includes asymmetric and symmetric keys. These public and private keys are made up of different types of algorithms such as RSA and Elliptic Curve Cryptography (ECC), which make them virtually impossible to crack. What is Asymmetric Encryption? Asymmetric Encryption, also known as Public Key Cryptography or SSL Cryptography, uses two separate keys for encryption and decryption. With asymmetric encryption, anyone can use the public key to encrypt a message. However, decryption keys are kept private. This way only the intended recipient can decrypt the message. The most common asymmetric encryption algorithm is RSA. RSA stands for Ron Rivest, Adi Shamir, and Leonard Adleman— the men who first publicly used the algorithm in 1977. Asymmetric keys are typically 1024- or 2048-bits. However, keys smaller than 2048-bits are no longer considered safe to use. 2048-bit keys have plenty of unique encryption codes with 617 digits in use. Though larger keys can be created, the increased computational burden is so significant that keys larger than 2048 bits are rarely used. To put it into perspective, it would take an average computer more than 14 billion years to crack a 2048-bit certificate. Asymmetric Encryption Diagram What is Symmetric Encryption? Symmetric Encryption (or pre-shared key encryption) uses a single key to both encrypt and decrypt data. Both the sender and the receiver need the same key to communicate. Symmetric key sizes are typically 128 or 256 bits—the larger the key size, the harder the key is to crack. For example, a 128-bit key has 340,282,366,920,938,463,463,374,607,431,768,211,456 encryption code possibilities. As you can imagine, a ‘brute force’ attack (in which an attacker tries every possible key until they find the right one) would take quite a bit of time to break a 128-bit key. Whether a 128-bit or 256-bit key is used depends on the encryption capabilities of both the server and the client software. TLS/SSL certificates do not dictate what key size is used. Symmetric Encryption Diagram Which is Stronger: Asymmetric Keys or Symmetric Keys? Since asymmetric keys are bigger than symmetric keys, data that is encrypted asymmetrically is tougher to crack than data that is symmetrically encrypted. However, this does not mean that asymmetric keys are better. Rather than being compared by their size, these keys should be compared by the following properties: computational burden and ease of distribution. Symmetric keys are smaller than asymmetric, so they require less computational burden. However, symmetric keys also have a major disadvantage—especially if you use them for securing data transfers. Because the same key is used for symmetric encryption and decryption, both you and the recipient need the key. If you can walk over and tell your recipient the key, this isn’t a huge deal. However, if you have to send the key to a user halfway around the world (a more likely scenario) you need to worry about data security. Asymmetric encryption doesn’t have this problem. As long as you keep your private key secret, no one can decrypt your messages. You can distribute the corresponding public key without worrying who gets it. Anyone who has the public key can encrypt data, but only the person with the private key can decrypt it. How does TLS/SSL use both asymmetric and symmetric encryption? Public Key Infrastructure (PKI) is the set of hardware, software, people, policies, and procedures that are needed to create, manage, distribute, use, store, and revoke digital certificates. PKI is also what binds keys with user identities by means of a Certificate Authority (CA). PKI uses a hybrid crypto-system and benefits from using both types of encryptions. For example, in TLS/SSL communications, the server’s TLS certificate contains an asymmetric public and private key pair. The session key that the server and the browser create during the SSL Handshake is symmetric.
Common Name (fully qualified domain name [FQDN] your certificate will secure) Country (two-digit code) State or Locality (full names e.g., California or Barcelona) Organization Name (full legal company or personal name as registered in your locality) Organization Unit (department in your organization the certificate is for [e.g., IT or Marketing]) Generating a CSR for a Wildcard Certificate? When generating a CSR for a Wildcard certificate, the common name must start with an asterisk (*) (e.g., *.example.com). The Wildcard character (*) can assume any name that doesn't have a dot character in it. 2048-Bit Key Length or higher is required To remain secure, SSL certificates must use keys that are 2048-bits in length or greater. Can't generate a CSR with a 2048-bit key on your server platform? Please contact us.
Don't worry, re-issue your active certificate with a new CSR and save the new corresponding private key on your server.
If the common name is incorrect, you need to cancel it first and then place a new order.
No, there is no such limitation. You are free it to install on servers in need.
1. CA will send the new certificate to order's technical email contact. 2. You may simply download it in your account panel, Certificate list - click download.
Yes, we can help you with TLS/SSL certificate installation. You can contact our support team and we can answer any questions you may have regarding installation. Also, you use our Installation Service which is as low as $20 per server.
Please reference our SSL Certificate Installation Instructions. You will need to select your Server Platform in the menu on the left. Please feel free to contact our support team so that we may further assist you if you still experience problems.
There is something wrong with the installation of your certificate. When correctly installed it will not give any warnings. Have you installed both the root and intermediate certificates? Incomplete installation is most likely the cause of the alert you are receiving.
Yes, no problem. To add additional domains, you may reissue your active certificate and enter in the desired domain(s). To start reissue process, login in your panel first and then click Reissue button when you are at certificate list page.
Firstly, login your account panel. Secondly, click Renew button next to certificate when you navigate to TLS/SSL list. Following instruction on the page, then here you go.
The best practice would be you create a new CSR and Private Key during the renewal process. This reduces any mismatches or errors during installation. You can use the original CSR and the corresponding Private Key if they are kept intact and safe.
Yes, you do. After renewal is completed, you will receive a new certificate which you will use to replace the current expiring certificate. If your site continue to use the original file, then the browser will display a warning once expiration occurs.
TLS/SSL certificates are not only used for encryption, they can also show that a Certificate Authority has verified your company. In this way, the certificate also works as verification of your business. When a Certificate Authority issues TLS/SSL certificates easily without verification steps, the internet becomes an unsafe place with high fraud risks. Before DigiCert issues a high assurance certificate, we verify the organizational details of the entity that applied for the certificate. Through this vetting process we build confidence in your customers while making the internet a safer place for everyone.
A blocklist check is a type of scan or URL/domain blocklist service. This scan (or service) is used to identify malware threats found on a URL/domain. Blocklist checks are included with premium DigiCert certificates like Secure Site and Secure Site Pro.
There are three levels of validation methods for TLS/SSL certificates. Extended Validation (EV) certificates require 16 methods of identity validation including verifying an organization’s name, status, type, registration number, jurisdiction, operational existence, physical address, phone number, employee contact, domain ownership, blocklist check and fraud check. Organization Validated (OV) certificates require nine validation checks about an organization’s type and status, and Domain Validated certificates only require one domain email verification.
Identity checks add an extra layer of security for digital certificates, thereby increasing trust in the certificate holder. By verifying the identity of certificate holders, Certificate Authorities (CAs) can confirm that the recipient has rights to the website domain, code or brand logo, for example, depending on the certificate type being issued. Identity checks come in the form of phone calls, in-person meetings, physical address verification, etc.