Generating a Certificate

Question

Generating a Certificate

Lucas Peñaloza 531

Dear,

     We have the following message, when trying to navigate the website:

User's image

We have our site hosted on an IIS server!!!.

We want to know what would be wrong?.

User's image

Perhaps we entered the name incorrectly on the certificate?

User's image

We see that the certificate is valid!!!.

User's image

What could be causing this error?

We were looking for information that details

The Common name property should be filled in with the server name (either a NetBIOS name or

FQDN) upon which the website will be answering requests. If the server’s name in the URL

being requested by a client does not match the common name in the certifi cate presented by

the server, the client will show an error!!!!.

But what is the common name?

Is this the information found in this field?

User's image

And this must be:

befancatalogo.personal.corp

Can you help us?

0 comments

3 answers

Your answer

Answer 1

Lex Li 6,042

In short, don't use IE for testing which reached end of life a while ago (since 2022),

https://learn.microsoft.com/lifecycle/faq/internet-explorer-microsoft-edge

You should use a modern browser that actually validates the certificates with modern rules.

Lucas Peñaloza 531 Reputation points

2026-05-04T13:58:42.1433333+00:00
Hi Lex,

OK.

In Google, show the same;

What do you think?
Lex Li 6,042 Reputation points

2026-05-05T15:05:52.5733333+00:00

You need to run a more extensive scan to see what other issues are there with the certificate.

I wrote a small utility for that in Jexus Manager,

https://docs.lextudio.com/jexusmanager/tutorials/ssl-diagnostics

And its report should tell what might be wrong.

Answer 2

Tom Tran (WICLOUD CORPORATION) 4,860 Microsoft External Staff Moderator

Hi @Lucas Peñaloza ,

Thanks for sharing your details.

From your screenshots, this looks like a certificate name mismatch.

The site is being accessed as:

https://befancatalogo.personal.corp

But the certificate configured in IIS appears to be issued to:

catalogo.personal.corp

Those names are different. A certificate can appear valid and still show a browser warning if the hostname in the URL is not included in the certificate. Microsoft’s IIS SSL guidance notes that browsers check the certificate validity period, trusted issuer, and whether the certificate Common Name matches the host header in the request.

Regarding your question about the Common Name, the field you pointed to is the Friendly Name. That is only a local label in Windows/IIS and is not used by the browser to validate the website name.

To check the actual name used by the certificate, open the certificate and look at:

Details > Subject
Details > Subject Alternative Name (SAN)

If users need to access the site as befancatalogo.personal.corp, then befancatalogo.personal.corp should be included in the certificate, preferably in the Subject Alternative Name (SAN) field.

If both names are required, then the certificate should include both:

catalogo.personal.corp
befancatalogo.personal.corp

After that, make sure the correct certificate is selected in the IIS HTTPS binding.

If the issue still persists after using a certificate with the correct hostname, then it would be worth checking the IIS binding configuration, such as SNI or whether multiple HTTPS sites are sharing the same IP address and port. But based on what is shown in the screenshots, the name mismatch already explains the browser warning.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance provide feedback.

Lucas Peñaloza 531 Reputation points

2026-04-30T14:42:42.0866667+00:00

Hi Tom;

We started verifying your comments!!!.

We regained access to the server, too.

We verified that the Field; Subject Alternative Name, has several records!!!.

Perhaps only the records should be there are:

befancatalogo.personal.corp and catalogo.personal.corp????.

We must request that all other records be deleted???.

Certificate in Subject, shows:

We understand that when the Certificate is created, the Registry, befancatalogo.personal.corp, must be in the common name field????.

Thank you for any help you can give us!!!!.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-05-01T09:24:34.29+00:00
Hi @Lucas Peñaloza ,

Thank you for checking the certificate details again.

From your latest screenshot, befancatalogo.personal.corp is already listed in the Subject Alternative Name (SAN) field. Because of that, you do not need to request a new certificate only because the Common Name is currently catalogo.personal.corp.

The Common Name is shown under Details > Subject. In your screenshot, it is:

CN = catalogo.personal.corp

However, since the certificate already has a Subject Alternative Name field, the hostname used in the browser should be checked against the SAN list. In your case, the SAN list includes:

DNS Name=befancatalogo.personal.corp

So this certificate should be valid for https://befancatalogo.personal.corp, assuming the browser is receiving this same certificate.

You also do not need to delete the other SAN entries just to fix this issue. A SAN certificate can contain multiple DNS names. Those extra entries only mean the certificate can also be used for those listed names. If those names should not be covered by this certificate, then you may request a cleaner certificate based on your internal policy, but the extra SAN entries are not the cause of the browser warning by themselves.

So to answer your questions directly:

No, befancatalogo.personal.corp does not necessarily need to be in the Common Name field if it is already included in the SAN field.

No, the other SAN records do not need to be removed just because they are present.

If the browser still shows the same warning, I would suggest opening the certificate directly from the browser warning on the client machine and comparing it with the certificate shown in IIS. If the browser shows a different certificate, then the next area to check would be the IIS binding/SNI configuration or whether another device, such as a load balancer or reverse proxy, is presenting a different certificate.
Lucas Peñaloza 531 Reputation points

2026-05-04T13:53:36.5433333+00:00

Hi Tom,

Thank you for your help!!!.

In a browser, We tried it:

In a Client Machine:

So, we understand that to verify the certificate, we do it from;

In this field, we understand that it musts show;

befancatalogo.personal.corp

We are wrong????

Thank you for your help.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-05-05T09:45:09.6133333+00:00
Hi @Lucas Peñaloza ,

You are checking from the correct place now. Opening the certificate from the browser is the right way to confirm what certificate the client machine is receiving.

For the field you highlighted, that is the Common Name (CN).

It does not necessarily need to show befancatalogo.personal.corp.

For Chrome and other modern browsers, the important field to check is usually Subject Alternative Name (SAN). If the SAN field contains: DNS Name=befancatalogo.personal.corp

then the hostname matching part should be OK, even if the Common Name shows catalogo.personal.corp.

So based only on this screenshot, I would not say the certificate is wrong just because the Common Name shows catalogo.personal.corp.

Please open the Details tab in the same certificate window and check:

Subject Alternative Name

Certification Path

If Subject Alternative Name includes befancatalogo.personal.corp, then the site name is already included in the certificate.

If Chrome still shows NET::ERR_CERT_INVALID, then the issue may be with another certificate validation check, such as the certificate chain or whether the issuing CA is trusted by the client machine.
Lucas Peñaloza 531 Reputation points

2026-05-05T14:28:28.2533333+00:00
Hi Tom,

Following up on your comments:

We opened the Certificate in Details tab:

We checked all the fields and they are not there:

Subject Alternative Name!!!.

At this point, we are lost!!!

Thank you for any help you can provide!!!.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-05-06T10:13:26.62+00:00
Hi @Lucas Peñaloza ,

Thank you for checking this again.

From the latest screenshot, Chrome is receiving a certificate for:

catalogo.personal.corp

You also mentioned that the certificate shown in Chrome does not have SAN. That is important because the site is being opened as:

https://befancatalogo.personal.corp

For Chrome, the certificate should include this name in SAN:

DNS Name=befancatalogo.personal.corp

If that SAN entry is missing from the certificate shown in Chrome, then the certificate error is expected.

The next step is to confirm whether Chrome and IIS are using the same certificate. Please compare the Thumbprint or Serial Number of both certificates:

In Chrome, open the certificate details and check the Thumbprint or Serial Number.

On the IIS server, open the certificate selected in the HTTPS binding and check the Thumbprint or Serial Number there.

Compare both values.

If the values are different, then Chrome is receiving a different certificate than the one selected in IIS. In that case, please check:

the IIS HTTPS binding

the SNI setting

other HTTPS bindings using the same IP address and port

any load balancer or reverse proxy in front of IIS

If the values are the same, and that certificate really has no SAN, then the certificate needs to be reissued with:

DNS Name=befancatalogo.personal.corp

After that, bind the new certificate to the HTTPS site in IIS.

The SSL diagnostic scan suggested by Lex Li can also help here, because it may show which certificate is being presented to the client and what certificate validation issue Chrome is detecting.

Answer 3

The error occurs because the hostname in the browser URL does not match the name(s) on the SSL certificate.

In the screenshot, the site is accessed as:

https://befancatalogo.personal.corp/

But the certificate is issued to:

catalogo.personal.corp

Browsers validate that the requested host name matches either:

The Common Name (CN) in the certificate’s Subject (older behavior), or
One of the Subject Alternative Name (SAN) DNS entries (current behavior).

If befancatalogo.personal.corp is not present as CN or in SAN, the browser shows:

The security certificate presented by this website was issued for a different website’s address.

So, in this case:

The common name is the value shown as Issued to (and in the Subject field), which is catalogo.personal.corp.
Because the site is bound in IIS with host name befancatalogo.personal.corp, the certificate is considered invalid for that URL.

To fix the problem, use one of these options:

Change the URL to match the certificate
Access the site as https://catalogo.personal.corp/ (and ensure DNS resolves that name to the IIS server).
Request/issue a new certificate with the correct name(s)
- Make befancatalogo.personal.corp the CN, or
- Add befancatalogo.personal.corp as a DNS entry in the SAN list (and optionally keep catalogo.personal.corp as well).
- Install the new certificate in IIS and update the HTTPS binding to use it.
Use a SAN certificate that covers both names if both URLs must be supported. The SAN list must include every hostname clients will use.

This behavior matches the documented cause where the URL being accessed is not listed in the certificate’s Subject or SAN, which leads to a name mismatch warning.

References:

Share via

Generating a Certificate

3 answers

Your answer