Skip to main content

Mutual Authentication

 

Mutual authentication, also known as two-way authentication, is a security process in which entities authenticate each other before actual communication occurs. In a network environment, this requires that both the client and the server must provide digital certificates to prove their identities. In a mutual authentication process, a connection can occur only if the client and the server exchange, verify, and trust each other's certificates. The certificate exchange occurs by means of the Transport Layer Security (TLS) protocol. The core of this process is to make sure that clients communicate with legitimate servers, and servers cooperate only with clients who attempt access for legitimate purposes.

The mutual authentication process involves the following certificates:

  • Root CA certificate
    Used to identify a certificate authority (CA) that signed a client's certificate. It is a self-signed certificate that meets the X.509 standard, defining the format of public key certificates. In IoT products, clients upload a root CA certificate or a certificate chain to verify that the certificates that client devices send to edge servers can be trusted. See Upload the Mutual Authentication root certificate.

  • Server SSL certificate
    Used to identify edge servers to client devices over TLS and to establish a secure connection during the TLS handshake. It is the enhanced TLS certificate that you provide in your property configuration. See Associate a property hostname to an edge hostname.

  • Client SSL certificate
    Used to identify client devices to edge servers over TLS. This certificate must meet the X.509 standard, defining the format of public key certificates.

The process of authenticating and establishing an encrypted channel using certificate-based mutual authentication involves the following steps:

  1. During configuration, administrators provide a root CA certificate or a certificate chain used to sign certificates on client devices. They can do it in Certificate Provisioning System (CPS). See Upload the Mutual Authentication root certificate.

  2. The OTA Updates application deploys the certificate chain to the ​Akamai​ Platform.

  3. Once the signing CA certificates propagate across the ​Akamai​ Platform, client device can connect by using MQTT, HTTP, or WebSocket protocols and request access to a topic.

  4. The edge server presents its certificate to the client device.

  5. The client device checks its list of trusted CAs and verifies the server's certificate.

  6. If successful, the client device sends its certificate to the edge server.

  7. The edge server checks its list of CAs and verifies the client device's certificate.

  8. If successful, a secure connection between the server and the client device is established.

ma-authenticating-establishing-encrypted-channel

How to verify a certificate chain

To pass certificate verification on edge servers, clients need to provide the root CA certificate or the root and intermediate certificates that signed the certificate that client devices use to identify themselves. The certificate authority and intermediate certificates, known as a certificate chain, is a list of certificates issued by successive certificate authorities (CAs) that enables edge servers to verify that the client and all CAs are trustworthy.

In the figure, you can see a certificate chain that leads from a certificate that identifies a client through two intermediary CA certificates to the CA certificate for the root CA. In the figure, you can see a certificate chain that leads from a certificate that identifies a client through two intermediary CA certificates to the CA certificate for the root CA.

ma-verify-certificate-chain

A certificate chain follows a path of certificates in the hierarchy up to the root CA certificate. In a certificate chain, each certificate must meet the following conditions:

  • Each certificate is followed by the certificate of its issuer.

  • Each certificate contains the name (DN) of that certificate's issuer, which is the same as the subject name of the next certificate in the chain.

  • Each certificate is signed with the private key of its issuer. The signature can be verified with the public key in the issuer's certificate, which is the next certificate in the chain.

System requirements

To configure mutual authentication properly and follow the procedures in this section, see the requirements for operating system and OpenSSL versions.

📘

Mutual authentication certificates in this guide have been created with the OpenSSL versions and on the operating systems indicated in the table. However, you can try their higher versions or other distributions.

Requirements for macOS, Linux, and Windows

RequirementmacOSLinuxWindows
Operating system versionMac OS X 10.15+Ubuntu 18.04.3 LTS+Windows 10+
OpenSSL versionLibreSSL 2.8.3+OpenSSL 1.1.1+OpenSSL v1.1.1g

Create a Mutual Authentication root certificate

To properly configure Mutual Authentication, you need to create a root certificate that you want to use to create and validate client certificates.

Before you begin

  • Make sure your environment meets the minimum requirements to complete this procedure. See System requirements.

  • Prepare a CA root certificate configuration file.

    An example of content in a root.conf file

  • [req]
    default_bits = 2048
    prompt = no
    default_md = sha256
    req_extensions = req_ext
    x509_extensions= v3_ca
    # subject distinguished name
    distinguished_name = dn
    
    [dn]
    # country
    C = US
    # state
    ST = Massachusetts
    # city
    L = Cambridge
    # organization
    O = Organization
    # organization unit
    OU = IoT
    # email
    emailAddress = test@email.com
    # common name
    CN = www.organization.test.com
    
    [req_ext]
    # subject alternative name
    subjectAltName = @alt_names
    # netscape comment
    nsComment = "This is netscape comment"
    
    [ v3_ca ]
    subjectKeyIdentifier=hash
    authorityKeyIdentifier=keyid:always,issuer:always
    basicConstraints = CA:true
    
    [alt_names]
    DNS.1 = test.example.com
    

All the files used in the task are in the same directory. The commands use these variables for the file names:

  • root.conf is the configuration file for the CA root certificate.

  • rootCA.crt is the CA root certificate you previously created.

  • rootCA.key is the CA root private key that you previously created.

How to

  1. Create a certificate key for your domain.

    You can use the following command: openssl genrsa -des3 -out rootCA.key 4096.

    A rootCA.key appears in your current directory.

  2. Using your CA root certificate key and the CA root configuration file, generate the CA root certificate.

    Make sure to set the basicConstraints value in the root.conf file to CA:true. This value indicates whether a certificate is a CA certificate.

    You can use the following command: openssl req -x509 -config root.conf -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt.

    A rootCA.crt file appears in your current directory.

  3. Upload the Mutual Authentication root certificate.

Upload the Mutual Authentication root certificate

In mutual authentication, the edge server asks the client device to present a valid certificate before a secure connection is established and the service of the server accessed. To verify the certificate that the device uses to identify itself, you need to provide edge servers with a root CA certificate or a certificate chain that signed the device's certificate.

To start verifying devices' certificates, you can upload a root CA certificate or a certificate chain in the Certificate Provisioning System (CPS). You can only upload one file that is a X.509 certificate in PEM format. A PEM certificate is a base64 encoded DER file that contains ----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- statements. If your CA provides you with a certificate that is not in PEM format, you can convert it to PEM format using an SSL converter.

Before you begin, use Trust Chain Manager to create a certificate set. Follow Trust Chain Manager.

  1. Go to > CDN > Certificates.

  2. Select the certificate that you want to use for Mutual Authentication.

  3. From the certificate's Actions menu, select View and Edit Deployment Settings.

  4. In the Mutual Authentication section, click Edit.

  5. From the Certificate set menu, select a certificate set.

  6. Click Submit.

    Your certificate redeploys to the ​Akamai​ network with the new settings.

Comments

Popular posts from this blog

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checking a shared sec

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into /opt/course/1/context_default_no_kubectl.sh , but without the use of k

标 题: 关于Daniel Guo 律师

发信人: q123452017 (水天一色), 信区: I140 标  题: 关于Daniel Guo 律师 关键字: Daniel Guo 发信站: BBS 未名空间站 (Thu Apr 26 02:11:35 2018, 美东) 这些是lz根据亲身经历在 Immigration版上发的帖以及一些关于Daniel Guo 律师的回 帖,希望大家不要被一些马甲帖广告帖所骗,慎重考虑选择律师。 WG 和Guo两家律师对比 1. fully refund的合约上的区别 wegreened家是case不过只要第二次没有file就可以fully refund。郭家是要两次case 没过才给refund,而且只要第二次pl draft好律师就可以不退任何律师费。 2. 回信速度 wegreened家一般24小时内回信。郭律师是在可以快速回复的时候才回复很快,对于需 要时间回复或者是不愿意给出确切答复的时候就回复的比较慢。 比如:lz问过郭律师他们律所在nsc区域最近eb1a的通过率,大家也知道nsc现在杀手如 云,但是郭律师过了两天只回复说让秘书update最近的case然后去网页上查,但是上面 并没有写明tsc还是nsc。 lz还问过郭律师关于准备ps (他要求的文件)的一些问题,模版上有的东西不是很清 楚,但是他一般就是把模版上的东西再copy一遍发过来。 3. 材料区别 (推荐信) 因为我只收到郭律师写的推荐信,所以可以比下两家推荐信 wegreened家推荐信写的比较长,而且每封推荐信会用不同的语气和风格,会包含lz写 的research summary里面的某个方面 郭家四封推荐信都是一个格式,一种语气,连地址,信的称呼都是一样的,怎么看四封 推荐信都是同一个人写出来的。套路基本都是第一段目的,第二段介绍推荐人,第三段 某篇或几篇文章的abstract,最后结论 4. 前期材料准备 wegreened家要按照他们的模版准备一个十几页的research summary。 郭律师在签约之前说的是只需要准备五页左右的summary,但是在lz签完约收到推荐信 ,郭律师又发来一个很长的ps要lz自己填,而且和pl的格式基本差不多。 总结下来,申请自己上心最重要。但是如果选律师,lz更倾向于wegreened,