Which table is most representative of the contents of the digital certificate?
In a world of mobile devices, bring your own device IT models and networks without borders, certificates are fast becoming a common form of identification. The use of certificates does not need to invoke a fight or flight response in network administrators, and can be simplified quite a lot. Show
The most difficult concept for many to understand is the concept of a public certificate vs. a private certificate. Certificates are part of Public-Key cryptography or asymmetric encryption. Asymmetric means that the two communicating devices will each encrypt and decrypt the data with different encryption keys. The term “key” may sometimes be thrown around and interchanged with the term “certificate”. There will be two keys, a public and a private key.
Items that are encrypted using your public key may only be decrypted with your private key. In the figure above, if endpoint C uses endpoint A’s public key to encrypt some data, it can only be decrypted by endpoint A. Similarly, if B uses C’s public key to encrypt data, that data may only be decrypted with C’s private key. So, what is a certificate?A certificate is a signed document that represents an identity. When thinking of a certificate, try to relate it to a passport, a driver’s license, or other personal identification card. That identification card is meant to represent you, and prove you are who you say you are. That certificate also contains the public key of that entity, so anyone with the public certificate will be able to encrypt data that only the certificate owner can decrypt. This section will discuss how certificate-based authentications actually work. When presented with a certificate, an authentication server will perform the following checks (at a minimum):
Let’s examine the above items one at a time. Determine if a Trusted Authority has Signed the Digital CertificateThe signing of the certificate really has two parts: The first part is that the certificate must have been signed correctly (following the correct format, etc). If it is not, it will be discarded immediately. The second part is the public certificate of the signing Certificate Authority (CA) must be in the list of trusted certificates (the trusted certificates store), and it must be trusted for purposes of authentication. When using Cisco ISE, a copy of the signing CA’s public certificate must be stored at Administration > System > Certificates > Certificate Store and it will need to have the “Trust for client authentication” use-case. Certificates are employed often in a network implementing Secure Access. The certificates are used to identify the Identity Services Engine (ISE) to an endpoint as well as to secure the communication between that endpoint and the ISE node. The certificate is used for all HTTPS communication as well as the Extensible Authentication Protocol (EAP) communication. HTTPS Communication Using the ISE CertificateEvery web portal with ISE version 1.1.0 and newer is secured using HTTPS (SSL encrypted HTTP communication). Examples include, but are not limited to:
This figure describes the SSL encrypted process when communicating to the Admin portal. EAP Communication:Certificates are used with nearly every possible EAP method. The main examples include: With tunneled EAP methods such as PEAP and FAST, Transport Layer Security (TLS) is used to secure the credential exchange. Much like going to an HTTPS web site, the client establishes the connection to the server, which presents its certificate to the client. If the client trusts the certificate, the TLS tunnel is formed. The client’s credentials are not sent to the server until after this tunnel is established, thereby ensuring a secure exchange. In a Secure Access deployment, the client is a supplicant, and the server is an ISE Policy Services node. As seen above, regardless of where the certificates are being used, the basic functionality is the same. The client must trust the server, and the keys from within the certificates are used to encrypt and decrypt the communication. The concept of Trust is a very important one. Whenever working with certificate based authentications, a fundamental question to always ask yourself is: “Does the client trust the server” and “does the server trust the client”. Note: In many cases, the server is not required to trust the client certificate. Clients may also be configured to not require the server certificate to be trusted. All of the options are configuration choices.Certificate TrustCertificates are similar to signed documents. When a client communicates to a secure server, the server will send it’s public certificate down to the client to be verified. The client will examine the certificate to determine if it should be trusted. The client is examining the certificate signer, and other attributes of the certificate, such as the subject. The Certificate SignerWhen establishing a secure connection, the client will validate that the signer of the certificate is a trusted authority. If the client does not trust the certificate signer, a warning with be displayed, such as the one displayed in the picture below. The client (Firefox browser) is establishing a secure connection to an ISE admin portal. The certificate used to secure that portal is a self-signed certificate (signed only by ISE itself and not by a known authority), and therefore the browser does not trust that signer. An Untrusted Certificate The Certificate SubjectThe certificate is created with a specific subject. That subject defines the entity it was created to protect. For example, if you examine the certificate that is used with https://www.cisco.com you will see a representation similar what is displayed below. The certificate used has a subject stating that this certificate was issued for securing www.cisco.com (the CN value of the certificate’s subject). Certificate from https://www.cisco.com In addition to a subject, a certificate may also have a subject alternative name (SAN). That extension to the certificate is designed to allow a single certificate be used to protect more than one fully qualified domain name (FQDN). Another way to look at that same statement is that many different FQDNs may point to the exact same secure site. Using the certificate from www.cisco.com as the example, there are values listed in the SAN field, such as: www1.cisco.com, www2.cisco.com and others. Subject Alternative Names What Certificate Values Should be Used with an ISE Deployment?With an ISE deployment, the administrator has a few choices related to using a single certificate for all identities or a mixture of different certificates, no more than one for each identity. That is a confusing statement. Let’s explain it a bit more. Each ISE node could have many different identities.
Here are examples of what certificates are being used for in the above diagram:
This is just a few example to try & solidify your understanding of where certificates are being used. The ISE administrator’s choice for how to break up these communications is very flexible. They can use one certificate per ISE node to secure all the different identities, they can use individual certificates for each service, they could use a single certificate and copy that certificate to each node in the deployment, or any combination of the above. The following sections will detail and illustrate three common ways of building ISE certificates. Model 1: Single Certificate per Node. Used for all ServicesThis method uses a single certificate per each ISE node (PAN, MnT, PSN). That certificate will be used for the admin, EAP, pxGrid functions as well as securing all portals. To accomplish that each certificate should be configured for:
Model 1: Each Node has it’s own Certificate There are Pro’s and Con’s of a Single Certificate per Node that is being Used for all Services Pro’sCon’sFollows the security best practices of a unique certificate per node.Many endpoints must accept the certificate for each PSNs EAP communicationUse of SAN’s is fairly easy in ISE 1.2+Are not using a different certificate on each portal.Keeps certificate management rather easyThe same certificate is used for admin that guests and employee users will be exposed to.Model 2: Multiple Certificates per Node. One for Each ServiceThis method uses a single certificate per function, per node. To accomplish that each certificate should be configured for: Admin Certificate (All ISE nodes get one):
pxGrid Certificate (All ISE nodes get one if you are using pxGrid):
EAP Certificate (All PSN’s get one):
Portal Certificate(s) (One or more per PSN):
Model 2: Different Certs per Function There are Pro’s and Con’s of a Separate Certificate per Node and per Service Pro’sCon’sFollows Security Best Practices of unique certificates per node, and goes further by providing unique certificates per node & per function.More certificates to manage per ISE nodes than Method 1Can be expensive to manage that many signed certificatesMany endpoint types must accept the certificate for each PSNs EAP communicationModel 3: Using the same certificate on all PSNsThis method uses the same private and public key-pair on all the ISE Nodes. This is often used for environments where there are a lot of BYOD-type devices. The main reason to follow this model is to ensure that the same exact certificate is used on all PSNs; so the BYOD devices will already trust any EAP server they must authenticate to. To accomplish this method, generate one certificate signing request (CSR) on a single ISE node. After binding the signed certificate to the private key, export the resulting key pair & import it on all the other nodes. Configure the single certificate for:
Model 3: Same Certificate on all Nodes There are Pro’s and Con’s of a Separate Certificate per Node and per Service: Pro’sCon’sBYOD type endpoints will not have to manually accept each cert for EAP authenticationsSecurity Best-Practices of unique certificates per identity are broken. Each ISE node appears identicalManagement is easyUsing a single certificate for admin and end-user facing functionsCertificate costs are kept downIf a new PSN node is ever added in the future, the certificate on every node will need to be updated to include the new FQDNIf it is not obvious, the ISE administrator is not limited to only these three models and is free to mix & match to fit whatever model is deemed most appropriate for the actual environment. The next sections will discuss another model altogether, the use of wildcard and what we are calling “wildSAN” certificates. What is a Wildcard Certificate?A wildcard certificate is one that uses a wildcard notation (an asterisk and period before the domain name) and allows the certificate to be shared across multiple hosts in an organization. An example CN value for a wildcard certificate’s Subject Name would look like the following: *.securitydemo.net If you configure a Wildcard Certificate to use *.securitydemo.net, that same certificate may be used to secure any host whose DNS name ends in “.securitydemo.net”, such as:
A wildcard is only valid in the host field of the fully qualified domain name (FQDN). In other words, *.securitydemo.net would not match ise.aaa.securitydemo.net, because the wildcard value was not in the host portion of the FQDN. Below is an example of using a wildcard certificate to secure a web site (specifically, the web interface of an ISE node). Notice that the URL entered into the browser address bar is “atw-lab-ise01.woland.com”, but the certificate’s common name is “*.woland.com”. Example Wildcard Certificate Note: Wildcard certificates secure communications in the same manner as a regular certificate, and requests are processed using the same validation methods.Why use Wildcard Certificates?There are a number of reasons to implement wildcard certificates with an ISE deployment. Ultimately, those who choose to use them, do so to ensure the end-user experience is as seamless as possible, especially given the vast difference and variety of endpoints. Benefits of Wildcard CertificatesSome benefits of wildcard certificate usage are:
Ultimately, wildcard certificates result in an improved user experience. Less prompting and more seamless connectivity will translate into happier users and increased productivity. Drawbacks to Wildcard CertificatesThere can be a number of benefits using wildcard certificates, but there are also a number of security considerations related to wildcard certificates including:
Although considered less secure than assigning a unique server certificate per ISE node, cost and other operational factors often outweigh the security risk and necessitate the need to offer this as an option to our customers in their ISE deployments. Note, that other security devices like the ASA also support wildcard certificates. You must always be careful when deploying wildcard certificates. For example if you create a certificate with *.securitydemo.net and an attacker is able to recover the private key, that attacker can spoof any server in the securitydemo.net domain. Therefore it is considered a best practice to partition the domain space to avoid this type of compromise. To address this possible issue and to limit the scope of use, wildcard certificates may also be used to secure a specific subdomain of your organization. Just add an asterisk (*) in the subdomain area of the common name where you want to specify the wildcard. For example, if you configure a wildcard certificate for *.ise.securitydemo.net, that same certificate may be used to secure any host who’s dns name ends in “.ise.securitydemo.net”, such as:
Wildcard Certificate CompatibilityWildcard certificates are most commonly constructed with the wildcard listed as the canonical name (CN) of the subject field of the certificate itself. ISE version 1.2 and newer support this manner of construction, however not all endpoint supplicants will support the wildcard in the subject of the certificate. All Microsoft native supplicants tested (including Windows Mobile) do not support wildcards in the subject of the certificate. The use of another supplicant, such as Cisco’s AnyConnect Network Access Manager (NAM), will allow the use of wildcard characters in the subject field. Another option is to use special wildcard certificates like DigiCert's Wildcard Plus that is designed to work on incompatible devices by including specific sub-domains in the Subject Alternative Name of the certificate. For more information on Microsoft’s support of wildcard certificates, see here: http://technet.microsoft.com/en-US/cc730460 Although the limitation with Microsoft supplicants may appear to be a deterrent to using wildcard certificates, there are alternative ways to construct the certificate that allow it to work with all devices tested with Secure Access, including the Microsoft native supplicants. Instead of constructing the subject to include the wildcard values, you may put those wildcard values into the Subject Alterative Name (SAN) field instead. The SAN field maintains an extension designed for the checking of the domain name, dNSName. See RFCs 6125 and 2128 for more detail, and a small excerpt from RFC 6125. This method is often referred to as the “WildSAN” method. Excerpt from RFC 6125 ISE Support for Wildcard CertificatesISE added support for wildcard certificates in version 1.2. Prior to version 1.2, ISE will perform verification of any certificates enabled for HTTPS to ensure the CN field matches the host Fully Qualified Domain Name (FQDN) exactly. If the fields did not match, the certificate could not be used for HTTPS. This restriction exists because prior to version 1.2, ISE would use that CN value to replace the variable in the url-redirect AV pair string. For all Centralized Web Authentication (CWA), on-boarding, posture redirection and more, the CN value would be used. Beginning in ISE version 1.2, the behavior has been modified to use the hostname and domain-name as it is defined in the underlying operating system (ADE-OS) configuration of ISE, instead of relying on the CN field of the certificate. The following CLI output example is showing the hostname and domain-name of an ISE node. atw-tme-ise134/admin# show run | i hostname Constructing the WildSAN CertificateSince we know we must insert the wildcard value into the Subject Alternative Name (SAN) field of the certificate as a workaround for Microsoft native supplicants, we are left with two main ways to construct the certificate. Option 1Leave the canonical name (CN) field of the subject blank and insert the wildcard into the SAN field.While this appears to work perfectly well with most private Certificate Authorities, such as the Microsoft Active Directory CA, the majority of Public authorities will not allow the creation of a certificate without the CN value. This is an example of a valid wildcard certificate without the CN field: Option 2(Cisco Preferred Best Practice) Use a generic hostname for the CN field of the subject, and insert both the same generic hostname and the wildcard value into the SAN Field. This method has been successful with the majority of tested public Certificate Authorities, such as Comodo.com and SSL.com. With these public CA’s the type of certificate to request is the “Multi-Domain Unified Communications Certificate” (UCC). Note: With both options, the resulting wildcard certificate only needs to used on the ISE nodes running Policy Services, it is not required to be used on the Policy Administration Nodes (PAN) or Monitoring and Troubleshooting (MnT) nodes.Now that we have reviewed wildcard certificates and their usage with ISE, we will walk through the creation of a wildcard certificate following the best practice of using a generic hostname for the CN field of the subject, and insert both the same generic hostname and the wildcard value into the SAN Field. Generate the WildSAN CertificateThere are a few ways to import a wildcard or wildSAN certificate into ISE version 1.3. This procedure will follow what we expect to be the most common approach, which is to create the Certificate Signing Request (CSR) within the ISE administrative interface and submit that CSR to the signing Certificate Authority (CA). The resulting signed public key will be bound to the CSR on ISE. The final private and public key-pair will be exported from the first ISE node, and imported on the other nodes in the deployment. Create the Certificate Signing Request (CSR)From the first ISE node, navigate to the certificates section of the administrative GUI. For dedicated Policy Services Nodes, the path will be Administration > System > Certificates > Certificate Signing Requests
Submit the CSR to the Certificate AuthorityNow that the CSR has been exported, it needs to be submitted to a CA for signing.
Import the CA Public Certificates to the Trusted Certificate StoreYou will now install the CA public certificate(s) into ISE’s Trusted Certificate store. This store maintains copies of the public certificate of any device that ISE “trusts”.
Repeat the Import process for each certificate authority. Bind the Newly Signed Certificate to the Signing RequestNow that ISE trusts the signing CA, it’s time to bind the signed certificate to the certificate signing request within ISE. From the ISE GUI:
Reuse the Same Certificate Pair on other ISE NodesIf you choose to do so, you could reuse the same certificate on the other ISE nodes. For more on reasons why, see the section titled “Example 3: Using the same certificate on all PSNs”. From the ISE GUI:
Now that the key-pair has been saved, you will need to extract the zip file from step 7, so the two certificate files may be accessed individually. Which of the following pieces of data is most likely to be considered PII?According to the NIST PII Guide, the following items definitely qualify as PII, because they can unequivocally identify a human being: full name (if not common), face, home address, email, ID number, passport number, vehicle plate number, driver's license, fingerprints or handwriting, credit card number, digital ...
Why was it important for the Diginotar certificates to be blacklisted?Why was it important for the Diginotar certificates to be blacklisted? The attacker could launch a DNS spoofing attack on the certificates' domains and then intercept private data from the domains' users.
What are the effects of revealing her bank account password to cyber criminals?What are the effects of revealing that password to the cyber criminals? The cyber criminals can sell her email and password combination to other attackers. The cyber criminals can try that password on the actual admissions tool and successfully gain access.
Which of these is a requirement for a computer to access the Internet?There are three ingredients needed to access the Internet from a laptop or desktop computer: (1) an ISP, (2) a modem and (3) a Web browser.
|