Exam 300-820 topic 1 question 41 discussion

Yep i feel the same, the answer is C

Correct answer should be D. There's no such a thing like a "temporary CA". An Issuer (CA) is an Issuer. It signs certificates. This is just the common name of the CA used to sign the certificate. It can be whatever. In this case TLS fails as stated in the Event Log Detail because of "tlsv1 alert unknown ca". This means that the certificate presented for the TLS negotiation is not trusted by the Exp-C, because of the lack of an intermediate or root certificate that signed the specific certificate. (public or private) So, either an intermediate is missing, or the root certificate of teh CA in the trust store is not there.

If TLS verify mode is enabled, the neighbor system's FQDN or IP address, as specified in the Peer address field of the zone’s configuration, is used to verify against the certificate holder’s name in the X.509 certificate presented by that system. (The name must be in the SAN attribute of the certificate.) The certificate itself must also be valid and signed by a trusted certificate authority. So when certificates have been generated with peer or cluster FQDNs, ensure that the zone's Peer address fields are configured with FQDNs rather than IP addresses. -https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X14-0-2/cert_creation_use/exwy_b_certificate-creation-and-use-deployment-guide-x1402/exwy_b_certificate-creation-use-deployment-guide_chapter_01000.html#concept_BFDB31BC4989A5EB232AF2A85AD1727E

Tough question. Could be A or D. Managing the Trusted CA Certificate List The Trusted CA certificate page (Maintenance > Security certificates > Trusted CA certificate) allows you to manage the list of certificates for the Certificate Authorities (CAs) trusted by this Expressway. When a TLS connection to Expressway mandates certificate verification, the certificate presented to the Expressway must be signed by a trusted CA in this list and there must be a full chain of trust (intermediate CAs) to the root CA. https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-9/Cisco-Expressway-Certificate-Creation-and-Use-Deployment-Guide-X8-9.pdf

SIP TLS Negotiation Failures on Neighbor and Traversal Zones If TLS verify mode is enabled, the neighbor system's FQDN or IP address, as specified in the Peer address field of the zone’s configuration, is used to verify against the certificate holder’s name in the X.509 certificate presented by that system. (The name must be in the SAN attribute of the certificate.) The certificate itself must also be valid and signed by a trusted certificate authority. So when certificates have been generated with peer or cluster FQDNs, ensure that the zone's Peer address fields are configured with FQDNs rather than IP addresses. https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X14-0-2/cert_creation_use/exwy_b_certificate-creation-and-use-deployment-guide-x1402/exwy_b_certificate-creation-use-deployment-guide_chapter_01000.html#concept_BFDB31BC4989A5EB232AF2A85AD1727E

Answer D: When a TLS connection to Expressway mandates certificate verification, the certificate presented to the Expressway must be signed by a trusted CA in this list and there must be a full chain of trust (intermediate CAs) to the root CA. Source https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-9/Cisco-Expressway-Certificate-Creation-and-Use-Deployment-Guide-X8-9.pdf

I feel answer is C

The ExpC is using a temporary CA, and it needs a certificate signed by a CA (either private or public).