Overview of the features of the Windows AD Certificate Services Family---certificates (1)

SSL security technology can be used in most Web sites, which are primarily used to handle important security data. SSL establishes a secure encrypted connection between the server and the client, most commonly the connection between the Web server and the browser or the email client on the client computer. SSL is recognized as a security protocol because it specifies cryptographic algorithms and necessary variables for encrypted connections, and the purpose of secure connections using SSL is to protect the data when it is passed between the server and the client, such as credit card numbers, login credentials, and other important data.

To establish a protected connection with SSL, you must install the certificate on the server, and both the internal CA and the public CA can issue certificates to SSL. For Internet-facing Web sites, certificates issued by the public CA authority are typically used because the certificates they issue are trusted by default, but you can also use certificates issued by your local CA. Both CA-issued certificates guarantee the security of the Web site, but most clients who visit the Web site cannot trust certificates that are issued using an internal CA. In fact, untrusted certificates still protect the connection, but it sends a warning message to the client when it connects to the Web site, and many companies do not want to have this warning message when they visit the site, so it is best to use public certificates for Internet-facing web sites. The Internet browser will pre-install a list of trusted CAs that will save the CA in this list to a trusted root certification authority.

When we choose to purchase a public certificate, it is important to note that not all public certificates are guaranteed to be automatically trusted by all clients, so before you buy, make sure that the certificate that you select is trusted globally and that its CA certificate is in a trusted root certification authority that is preinstalled by the client.

Use SSL certificates to secure connections

Each certificate will have a pairing key after it is issued, and the pairing key consists of a public key and a private key, both of which are used during cryptographic processing, where the data encrypted with the public key can only be decrypted with its corresponding private key, and vice versa, each pairing key is unique.

In addition to the pairing key, each certificate has its object name, which is used to identify which server or Web site The certificate is installed on. When using a Web browser to access a protected web site, the client and server establish an SSL connection, which is established during the SSL handshake, the following steps:

1. User enters an HTTPS URL in the Web browser

2. The Web browser connects to the Web site and requests the server to verify its identity

3. The Web server sends its SSL certificate to the client, and the certificate contains the public key of the certificate

4. The client checks the server's certificate, examines the certificate's object name, compares the object name to the URL of the access server, checks whether the certificate was issued by the Root Trust certification authority, and confirms in the certificate revocation list distribution Point whether the certificate has been revoked.

5. If all the checks are passed, the client generates a symmetric encryption key that the client and server can use to decrypt the data, because the pairing key of the public and private key is inefficient in the operation of encrypting and decrypting large amounts of data, so the client generates a symmetric secret key. The symmetric key is then encrypted through the server's public key and the client sends the encrypted symmetric key to the server.

6. The server uses its private key to decrypt the received symmetric key, and now the server and client have the same symmetric secret key, and the data can be transferred securely between the two.

The above procedure contains several very important checks, the first time the server presents its SSL certificate to provide its own identity to the client, if the server name in the certificate matches the URL of the client request, and the certificate is issued by a trusted authority, The client trusts and considers the server to be a valid identity. In addition, the client checks the validity of the certificate, checks the certificate's life cycle, and checks the certificate revocation list for any objects that match the certificate. So establishing an SSL session is not just about managing encryption, but also performing validation actions from the server to the client.

Note: client-side validation is not included in the regular SSL handshake, meaning that the client can not submit its own identity to the server, but you can configure your site to require the client to authenticate, and the client can use a certificate to authenticate itself.

Configure an SSL certificate on the server

To secure communication between the server and the client over SSL, you must install the certificate on the server. You have several ways to install the certificate, but before you install the certificate, you must define the name of the certificate or the name that the certificate supports. For example, if you want to protect a Web site with a URL of www.adatum.com, you need to issue a common name www.adatum.com certificate.

Note: Certificates can only be issued based on the server name or alias and do not require a full URL. For example, the common name Www.adatum.com certificate can also protect the URL is www.adatum.com/sales or similar sites.

At some point you may need to use multiple server name certificates on the same server, the most typical case being the Exchagne Client Access server (CAS), the CAS-installed certificate must support its public name, For example mail.adatum.com and autodiscover.adatum.com, because these two names are related to the same site, but a site can only bind a certificate, so you have a can support a multi-name certificate, this certificate is also known as the object optional name certificate, the certificate can use multiple names, W Indows 2012 of CAs and public CAs can issue this certificate.

Note: In the same domain, we can also issue a wildcard certificate in place of a multi-name certificate, such as issuing a certificate with the common name of *.adatum.com, which is valid for all names with the domain name suffix adatum.com, but is not recommended for security reasons.

An SSL certificate is issued through an internal CA, which can be done in the following ways:

1. Use the CA console on the server to submit a certificate request to the CA. This method can specify any additional attributes for the certificate, such as a certificate target or an object alternative name, but after the certificate has been installed, you must manually assign the certificate to the applicable Web site.

2. Use the IIS console. In the IIS console, you can request a certificate directly from the CA, but the certificate you requested in this way cannot select a certificate template, it uses the Web server template by default, and you cannot specify an optional name for the object. But this method also has its advantage, it is the simplest way to install the certificate on the website.

3. Use CA Web enrollment. This method is suitable for issuing certificates to those non-domain servers, using this type of registration, you first need to have a certificate request file (. reg format), and then submit this file on the CA Web enrollment page, this method can specify the certificate template and add object optional name.

If you purchase a public trust SSL certificate, these procedures will be somewhat different, after you choose a certificate provider, you first have to pass a management process, this management process is used to verify the identity of your company and domain name ownership, after you complete this process, you have to establish a certificate signing request on your server ( CSR Certificate Signing Request), the CSR establishes a private key and a CSR data file, and then you send the CSR to the certificate issuer, which uses the CSR data file to create a public key to match your private key without having to hack the key. In addition to configuring the certificate archive, the CA will never view the certificate's private key or the operation before the certificate was issued, but even if the certificate archive is configured, the secret key is encrypted.

Use of certificates in digital signatures

In addition to protecting communications, certificates can be used to protect content and verify the identity of content authors. When you receive information about a confidential content, there are two key things we need to confirm: first, this information is not modified at the time of delivery, and secondly, the author's identity is verifiable. You can use certificates to protect and validate content, and to verify the identity of the author, the most common example being a user digitally signing a document.

Digital signature:

When someone digitally signs a document in the application, he confirms that the document is reliable. Reliable here means that the creator of the document is known and that the document has not been altered in any way since it was created and signed. PKI is able to achieve this level of security, compared to our previous Web server certificate, the user will also have a pairing key, the certificate will be used in the process of data signing.

When an author digitally signs a document or information, his computer's operating system creates an information password digest, which is a 128bit-256bit-length number that the operating system generates by executing a hash algorithm for the entire information. The number is then encrypted by the author's private key and added to the end of the document or message.

When a document or information is received by the recipient, the recipient's operating system also runs a hashing algorithm on the document or information to generate the information Password digest, which is identical to the hash algorithm executed at the author's end. The recipient then decrypts the Password digest in the received document using the author's public key, and the decrypted password summary is compared to the password digest generated by the recipient, and if the two are the same, then the document or information has not been modified during the transfer. In addition, if the recipient is able to use the author's public key to decrypt the password digest, the password digest is encrypted using the author's private key, which is equivalent to verifying the author's identity. The final recipient also verifies the certificate used to indicate the identity of the author, and it also checks the validity of the certificate, the CRL, the object name, and the certificate chain Trust.

To deploy a digital signature:

To deploy digital signatures in internal communications, you need to issue certificates based on user templates, you must issue certificates to all users who use digital signatures, and you do not need user intervention if you use automatic enlistment to publish certificates. Users must use an application that supports content signing, for example, you can use the default digital signature for Word and outlook.

After you have issued a certificate and configured your application, you can use a digital signature, but if you want to send digitally signed content outside your company, you may experience CA trust issues, such as that the recipient and author are not in the same ad domain. So the recipient does not trust the certificate that was issued by the CA in the domain of the author for the digital signature, although the digital signature is still valid in terms of content protection, but when the recipient uses the application it generates a warning message and cannot access the protected content.

If you need to send digitally signed content to a recipient outside your company, it's a good idea to use a certificate issued by a public CA that is trusted by the world.

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1590183

Overview of the features of the Windows AD Certificate Services Family---certificates (1)