How to check a website’s SSL certificate from a verification page

A robot-verification page can hide the substantive page you expected, yet the browser still exposes the exact hostname, connection status and certificate behind the current request. That makes the interruption useful: you can inspect the site’s SSL certificate from a verification page before selecting a verification button, downloading anything or entering personal details. It also helps you notice when the challenge is hosted somewhere unexpected.

A valid certificate is only one trust signal. It confirms that the connection to a particular host is encrypted and that the host demonstrated control of the requested name. It does not establish that the organisation is legitimate, that prices are genuine or that information submitted through the page will be handled responsibly. Those checks require separate business and security evidence.

Separate the challenge from the destination

Verification challenges are often delivered by the same website through a path such as /verify or through an embedded script. In that case, the certificate displayed by the browser normally belongs to the website named in the address bar. Some challenges, however, are supplied by a separate verification provider. The main address may remain unchanged while the page loads code from another domain, or a challenge may redirect you to a provider-specific address before returning you to the site.

A certificate for challenge-provider.com tells you that the provider controls its own hostname and that your connection to it is encrypted. It says nothing directly about the certificate of the business you hoped to reach. The relevant host can also change after you select the verification control, so the destination must be checked both before and after the challenge.

The certificate therefore answers a narrow question: which named server is involved in this encrypted connection? Record the hostname, issuer and validity dates, but treat them as technical evidence rather than a general endorsement of the business.

Inspect security details in your browser

In Chrome or Edge, select the tune or padlock icon beside the address and look for a statement such as “Connection is secure”. Open the certificate details, usually labelled “Certificate is valid”. In Firefox, select the padlock or site identity icon, open the connection information and follow the certificate link. Safari and some mobile browsers provide fewer certificate details, so a desktop browser may be needed for a detailed check.

Read four fields where available. First, confirm the domain name issued the certificate. Check the Subject Alternative Name when it is shown, rather than relying only on the common name. Second, note the certificate authority or issuer. Familiar names can provide mild reassurance, but unfamiliar issuers are not automatically fraudulent. Third, check the valid-from and valid-to dates. Finally, record the serial number or fingerprint if you need to compare the certificate with details supplied by the organisation.

Treat an expired certificate, a hostname mismatch or a severe browser warning as reasons to stop. Do not click through the warning merely because the page promises a solution. A managed work device may display an organisation’s TLS-inspection certificate instead of the public certificate. That can be legitimate, but the device administrator should confirm its purpose before you continue.

Match every hostname and redirect

Compare the certificate name character by character with the hostname you intended to visit. A certificate for www.example.com.au does not necessarily cover example.com.au, and a certificate for accounts.example.com.au does not prove control of example.com.au. Many sites request both versions, but this should be confirmed rather than assumed. A wildcard such as *.example.com.au generally covers one subdomain level, not the root domain or deeper names such login.secure.example.com.au.

Watch the address bar throughout the verification process. A legitimate challenge may redirect to a provider and then back to the original domain, but each host should have a clear connection to the transaction. Embedded challenges can be harder to identify because they load in the page without replacing the top-level address. Opening browser site permissions can reveal third-party domains, while selecting the verification control may expose a later redirect.

Even a perfect hostname match does not make a page safe. A fraudulent site can obtain a genuine certificate, serve it without errors and use the encrypted connection to collect identity documents, banking credentials or cryptocurrency. Encryption protects data in transit; it does not reveal the server operator’s intentions.

Apply Australian business and safety checks

For an Australian business, check the domain format before relying on it. A .com.au address should normally be connected to an Australian presence and an eligible registrant under the current auDA rules. Direct .au domains are also available. Registration alone is not proof that the business is active, and commercial domain brokers may appear in the registration record, so the domain listing should be treated as one source rather than a complete identity check.

Look for the legal or trading name, Australian Business Number and Australian GST treatment where relevant. The Australian Business Register can help confirm whether the displayed business name and ABN belong together, although neither prevents identity misuse. For local services, compare the contact details with information published elsewhere rather than only with the verification page. A business serving Sydney, Melbourne or Brisbane may state opening hours in AEST or AEDT, and quotes should ordinarily identify the entity, services and GST treatment. Never rely on a phone number printed only on the suspicious page when checking a payment instruction; use the bank’s official app or a verified number.

The Australian Government’s Scamwatch advice and eSafety guidance provide useful warning signs for phishing, remote-access scams and payment redirection. If the page requests remote access, urgency, gift cards or cryptocurrency, preserve the URL and screenshots, contact the institution through a trusted channel and report the incident. For privacy concerns involving personal information, the Office of the Australian Information Commissioner is the relevant national authority.

Handle warnings without weakening security

Security software can flag verification scripts, unfamiliar downloads or recently registered domains. That does not make every alert harmless, but it also does not justify switching off the firewall, antivirus or browser protections. A controlled whitelisting guide can help explain how narrow exclusions work if you have confirmed that a specific host is safe.

Any exception should cover only the exact domain and component that caused the alert. Review it later, remove it when the task is finished and avoid allowing an entire browser extension, executable file or security category. Whitelisting changes the protective boundary, so it should follow investigation rather than precede it. An administrator who cannot explain which process generated the warning should keep the protection in place and investigate the site from another device.

Corporate-managed devices need a different response. They may route traffic through a proxy that decrypts and inspects content, producing a certificate in the employer’s name. Ask the IT team to verify the issuer, inspect the warning and confirm the destination. On a personal device, unexpected issuer names, certificate warnings or security-tool alerts are stronger reasons to pause before entering payment or identity information.

Use a repeatable verification routine

A consistent routine makes it easier to separate technical anomalies from ordinary challenges:

• Confirm that the address uses HTTPS and that the hostname exactly matches the business you intended to contact.
• Open the certificate panel and record the issued name, issuer, validity dates and any warning shown by the browser.
• Check whether the verification challenge redirects through another provider and whether it returns to the expected domain.
• Compare the business name, ABN, phone number, email domain and physical location with independently sourced records.
• Review requests for credentials, remote access, unusual payment methods, downloads or unnecessary personal information.
• Keep security software enabled and limit any approved exception to the specific host and component involved.

Document what you observed, including the date and time in AEST or AEDT, so another person can reproduce the check. The Three Percent Solution site can serve as an additional reference while you assess the wider security context surrounding a transaction.

The concrete next step is to open the certificate panel for the site you intended to visit, record its hostname, issuer and expiry date, and compare the hostname character by character with the address you entered.