Mutual TLS between services in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the protocol used for secure communication between services.

Microservices

protocol = "[1]"

Drag options to blanks, or click blank then click option'

Ahttp

Bftp

Chttps

Dsmtp

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'http' which is not secure.

Confusing with other protocols like FTP or SMTP.

The protocol for secure communication using TLS is HTTPS, which encrypts data between services.

2fill in blank

medium

Complete the code to load the client certificate for mutual TLS authentication.

Microservices

client_cert = load_certificate("[1]")

Drag options to blanks, or click blank then click option'

Aclient.crt

Broot.crt

Cca.crt

Dserver.crt

Attempts:

3 left

💡 Hint

Common Mistakes

Using the server certificate instead of client certificate.

Using CA or root certificates which are for verification, not client identity.

The client certificate file is needed for the client side in mutual TLS to authenticate itself to the server.

3fill in blank

hard

Fix the error in the code to enable mutual TLS by setting the correct verification mode.

Microservices

ssl_context.verify_mode = ssl.CERT_[1]

Drag options to blanks, or click blank then click option'

ANONE

BOPTIONAL

CIGNORE

DREQUIRED

Attempts:

3 left

💡 Hint

Common Mistakes

Setting verify_mode to NONE or IGNORE disables client verification.

OPTIONAL allows clients without certificates, which is not mutual TLS.

For mutual TLS, the server must require the client certificate, so verify_mode should be CERT_REQUIRED.

4fill in blank

hard

Fill both blanks to configure the server to load the CA certificate and enable client certificate verification.

Microservices

ssl_context.load_verify_locations("[1]")
ssl_context.verify_mode = ssl.CERT_[2]

Drag options to blanks, or click blank then click option'

Aca.pem

Bclient

CREQUIRED

DOPTIONAL

Attempts:

3 left

💡 Hint

Common Mistakes

Using client certificate file instead of CA certificate file.

Setting verify_mode to OPTIONAL disables strict client verification.

The server loads the CA certificate file (ca.pem) to verify client certificates and sets verify_mode to CERT_REQUIRED to enforce verification.

5fill in blank

hard

Fill all three blanks to create a secure client connection with mutual TLS by specifying client cert, key, and CA cert files.

Microservices

connection = create_tls_connection(client_cert="[1]", client_key="[2]", ca_cert="[3]")

Drag options to blanks, or click blank then click option'

Aclient.pem

Bclient.key

Cca.pem

Dserver.pem

Attempts:

3 left

💡 Hint

Common Mistakes

Using server.pem instead of client.pem for client certificate.

Omitting the client key or CA certificate.

The client needs its certificate (client.pem), private key (client.key), and the CA certificate (ca.pem) to establish mutual TLS.

Practice

1. What is the main purpose of using Mutual TLS between microservices?

easy

A. To allow services to communicate without encryption

B. To speed up the communication between services

C. To ensure both services authenticate each other before communication

D. To store service data securely on disk

Solution

1. Step 1: Understand Mutual TLS authentication

   Mutual TLS requires both client and server to present certificates proving their identity.

2. Step 2: Identify the purpose in microservices

   This ensures only trusted services communicate securely, preventing unauthorized access.

3. Final Answer:

   To ensure both services authenticate each other before communication -> Option C

4. Quick Check:

   Mutual TLS = mutual authentication [OK]

Hint: Mutual TLS means both sides prove who they are [OK]

Common Mistakes:

• Thinking it only encrypts data without authentication
• Assuming it speeds up communication
• Confusing it with data storage security

2. Which of the following is the correct step to enable Mutual TLS in a microservice?

easy

A. Disable certificate verification on both services

B. Share the same private key among all services

C. Use plain HTTP instead of HTTPS

D. Configure each service with its own certificate and trust store

Solution

1. Step 1: Identify certificate requirements

   Each service must have its own certificate and trust store to verify others.

2. Step 2: Understand security best practices

   Disabling verification or sharing keys breaks security and is incorrect.

3. Final Answer:

   Configure each service with its own certificate and trust store -> Option D

4. Quick Check:

   Certificates + trust store = Mutual TLS setup [OK]

Hint: Each service needs its own certificate and trust store [OK]

Common Mistakes:

• Disabling certificate verification to simplify setup
• Using HTTP which is unencrypted
• Sharing private keys causing security risks

3. Given two microservices A and B configured with Mutual TLS, what happens if service B presents an expired certificate during handshake?

medium

A. Service A accepts the connection without checks

B. Service A rejects the connection due to invalid certificate

C. Service B automatically renews the certificate

D. The connection proceeds but logs a warning

Solution

1. Step 1: Understand certificate validation in Mutual TLS

   Certificates must be valid and trusted; expired certificates are rejected.

2. Step 2: Identify handshake behavior on invalid certificates

   If service B's certificate is expired, service A will reject the connection to maintain security.

3. Final Answer:

   Service A rejects the connection due to invalid certificate -> Option B

4. Quick Check:

   Expired certificate = connection rejected [OK]

Hint: Expired cert means connection is rejected [OK]

Common Mistakes:

• Assuming expired certs are accepted with warnings
• Thinking certificates auto-renew during handshake
• Believing connection proceeds without checks

4. A microservice fails to establish Mutual TLS with another service. The error logs show "certificate unknown". What is the most likely cause?

medium

A. The service's certificate is not signed by a trusted CA

B. The service is using HTTP instead of HTTPS

C. The private key is missing from the service

D. The service is using a self-signed certificate but trusts it

Solution

1. Step 1: Analyze the error "certificate unknown"

   This error means the certificate presented is not recognized or trusted by the other service.

2. Step 2: Identify cause related to trust

   If the certificate is not signed by a trusted CA, the other service will reject it as unknown.

3. Final Answer:

   The service's certificate is not signed by a trusted CA -> Option A

4. Quick Check:

   Untrusted CA = certificate unknown error [OK]

Hint: Certificate unknown means untrusted CA signature [OK]

Common Mistakes:

• Confusing HTTP usage with certificate errors
• Assuming missing private key causes this error
• Believing self-signed certs are trusted by default

5. You need to design a microservices system with Mutual TLS where services dynamically scale up and down. Which approach best ensures secure and scalable certificate management?

hard

A. Use a centralized certificate authority with automated certificate issuance and rotation

B. Manually generate and distribute certificates to each service instance

C. Disable Mutual TLS during scaling to avoid certificate issues

D. Use the same certificate for all service instances to simplify management

Solution

1. Step 1: Understand challenges of scaling with Mutual TLS

   Dynamic scaling requires automated certificate management to avoid manual errors and delays.

2. Step 2: Evaluate options for secure and scalable management

   A centralized CA with automation allows issuing and rotating certificates securely as instances scale.

3. Step 3: Reject insecure or manual approaches

   Manual distribution is error-prone, disabling TLS reduces security, and sharing certificates risks compromise.

4. Final Answer:

   Use a centralized certificate authority with automated certificate issuance and rotation -> Option A

5. Quick Check:

   Central CA + automation = scalable Mutual TLS [OK]

Hint: Automate certs with central CA for scaling [OK]

Common Mistakes:

• Manually managing certs for each instance
• Disabling Mutual TLS to avoid complexity
• Sharing certificates across instances