SY0-701 General Security Concepts Practice Question
Exhibit
$ openssl s_client -connect pay.example.net:443 -servername pay.example.net CONNECTED(00000003) depth=0 CN = portal.example.net verify error:num=62:hostname mismatch verify return:1 --- Certificate chain 0 s:CN = portal.example.net i:CN = Example Issuing CA a:PKEY: rsaEncryption, 2048 (bit) Not After : May 10 2026 ---
Based on the exhibit, users report that the new payment portal opens only after they bypass a browser warning. Which remediation best restores secure access without weakening certificate validation?
⚠ Common exam trap
It's easy for candidates to think installing the same certificate on clients (Option A) is a valid fix, but this violates certificate security by exposing the private key and does not address the root cause of the hostname mismatch.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Reissue the server certificate so the subject or SAN matches pay.example.net and chain it to the trusted CA.
The browser warning indicates a hostname mismatch or untrusted CA. Reissuing the server certificate with the correct subject or SAN (Subject Alternative Name) matching pay.example.net and chaining it to a trusted CA resolves the warning while maintaining full certificate validation. This ensures the browser can verify both the identity and trustworthiness of the server without weakening security.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Install the same certificate on every client so the browser warning is suppressed.
Why it's wrong here
Installing the same certificate on every client will not suppress the browsing warning because the warning is triggered by a hostname mismatch between the certificate's Subject/SAN and the requested domain (pay.example.net). Client-side trust stores only determine which Certificate Authorities are accepted; they do not override hostname verification for the server's certificate. Moreover, distributing the certificate's private key to every client is a severe security risk, as any recipient could impersonate the server, and it creates an unmanageable key-distribution and revocation problem across all endpoints.
- ✓
Reissue the server certificate so the subject or SAN matches pay.example.net and chain it to the trusted CA.
Why this is correct
A valid server certificate must match the hostname users are connecting to, and it must chain to a trusted issuing authority. Reissuing the certificate for pay.example.net resolves the mismatch shown in the exhibit while preserving proper certificate validation.
- ✗
Disable certificate name checking in the browser until the certificate expires.
Why it's wrong here
Disabling certificate name checking bypasses the browser’s Subject Alternative Name (SAN) validation, which would allow the portal’s certificate to match any domain, defeating the purpose of certificate validation entirely. This is tempting because name mismatches are a common cause of browser warnings, and disabling the check would suppress the alert without replacing the misconfigured certificate. In a controlled lab environment where a self-signed certificate is used for testing, disabling name checking can be a temporary workaround, but it is never a secure remediation for a production payment portal.
- ✗
Replace TLS with a shared symmetric key configured on the web server and all users.
Why it's wrong here
Replacing TLS with a shared symmetric key configured on the web server and all users is impractical and insecure for a public payment portal. Distributing a single shared secret to every user is logistically impossible without a secure out-of-band channel, and any compromise of that key would allow an attacker to decrypt all traffic or impersonate the server. Symmetric-key systems lack authentication of the server's identity, non-repudiation, and the scalability of a PKI; they provide no way to establish trust or revoke individual users' access, which is why they cannot replace certificate-based TLS for public-facing services.
Visual reference
Go deeper
Related to this question
Learn chapter
Security Controls
Key term
Identity
Identity is the unique set of attributes that defines a user, device, or service in a computer system, determining what they can access and do.
Key term
Security
Security in IT is the practice of protecting systems, networks, and data from unauthorized access, damage, or theft.
About these practice questions
This SY0-701 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.