Generating a Certificate

Question

Generating a Certificate

Lucas Peñaloza 536

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 536 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) 5,295 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 536 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) 5,295 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 536 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) 5,295 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 536 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) 5,295 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.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-05-08T10:55:07.43+00:00

Hi @Lucas Peñaloza ,

I'm just checking in to see if you have any questions, please feel free to comment below. I'll be happy to assist.
Lucas Peñaloza 536 Reputation points

2026-05-08T19:50:35.9833333+00:00

Hi Tom,

So,

In Chrome, opened the certificate details and we verified the Thumbprint or Serial Number.

But in Subject, the Certificate, shows:

At this point, we have some doubts!!!!.

I shouldn't say: befancatalogo.personal.corp???.

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

It show:

We are seeing that it says issued for: catalogo.personal.corp!!!.

And we have the same doubt again, I shouldn't say: befancatalogo.personal.corp???.

In Details;

Field - Serial number:

Field Subject:

Field thumbprint

We are thinking that the field that the Certificate takes is CN!!!!.

In CN, It should say: befancatalogo.personal.corp!!!.

Now, It say: catalogo.personal.corp

What do you Think????.

Another question we are having is about the Certificate Hierarchy!!!.

We should be able to see the details of the Certificate???.

The "view certificate" option is grayed out!!!.

The certificate serial number displayed in the Google browser does not match the serial numbers on the certificates; we understand that Root - Intermediate!!!!.

In other words, the same certificate, in:

Personal Certificates

Intermediate Certification Authorities

Certificates

Perhaps the Intermediate Certificate should be different?
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-05-11T10:34:26.4+00:00
Hi @Lucas Peñaloza ,

Thank you for the detailed screenshots. They help a lot.

After comparing both certificates, the serial numbers do not match:

Chrome: 1C:F6:D2:8F:00:02:00:25:C5:64

IIS: 1c00001decf4ed018cbe6e695e000100001dec

The certificate chains are also different:

Chrome: ROOTCATELECOM > IssuingCATelecom

IIS: RootCAGrupoTelecom > IssuingCAGrupoTelecom

So Chrome is receiving an older certificate than the one currently selected in IIS. This can happen when IIS Manager shows the updated certificate, but HTTP.sys is still serving the previous one.

There are also two other things worth noting from your screenshots:

1. Two certificates with the same name in the Personal store.

Your MMC shows two certificates named catalogo.personal.corp:

One issued by IssuingCATelecom, expires 06/10/2026

One issued by IssuingCAGrupoTelecom, expires 11/03/2028

Having two certificates with the same name can cause confusion about which one HTTP.sys actually serves.

2. The server certificate is in the Intermediate Certification Authorities store.

Your last screenshot shows catalogo.personal.corp under Intermediate Certification Authorities > Certificates. That store should only contain CA certificates, not the server certificate. The server certificate should only be in the Personal store.

I would suggest the following steps:

On the IIS server, run: netsh http show sslcert This will list all SSL bindings. Look for the entry on port 443 that matches your site. It will show as either IP:port or Hostname:port format, along with the Certificate Hash. Compare that Certificate Hash with the thumbprint of the certificate you want to use.

If the Certificate Hash points to the old certificate, delete the old binding using the matching format: If the binding shows as IP:port: netsh http delete sslcert ipport=0.0.0.0:443 If the binding shows as Hostname:port: netsh http delete sslcert hostnameport=befancatalogo.personal.corp:443

Remove catalogo.personal.corp from the Intermediate Certification Authorities store.

Rebind the correct certificate to the HTTPS binding in IIS.

Run netsh http show sslcert again to confirm the certificate hash now matches the correct thumbprint.

Test again in Chrome.

One more thing: if the newer certificate (expires 2028) does not contain SAN with:

DNS Name=befancatalogo.personal.corp

then Chrome will still show a certificate error even after fixing the binding. In that case, the certificate would need to be reissued with that SAN entry.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-05-13T11:03:18.5+00:00

Hi @Lucas Peñaloza ,

I'm just checking in to see if you have any questions, please feel free to comment below. I'll be happy to assist.
Lucas Peñaloza 536 Reputation points

2026-05-19T01:59:34.6266667+00:00
HI Tom,

Sorry,

But we've been dealing with other issues; we'll get back to this one soon!

It's another matter that's still pending.

Thank you very much for your patience.
Lucas Peñaloza 536 Reputation points

2026-05-22T18:46:50.42+00:00

Hi Tom,

Getting back to this topic!!!

On the IIS server, run: netsh http show sslcert.

This will list all SSL bindings.

Compare that Certificate Hash with the thumbprint of the certificate you want to use.

Certificate Hash in IIS:

4b0304ce561921f4f40a81e3a149c29f45029cfd

But where can we see this data in the browser?

It will be the field

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

2026-05-25T11:02:08.7366667+00:00
Hi @Lucas Peñaloza ,

Sorry for the late response.

The field shown in your screenshot is Serial Number. That is not the value we need to compare with the Certificate Hash from netsh.

For this check, please use the Thumbprint field.

In Chrome, please click/select this certificate first:

catalogo.personal.corp

Please do not select:

IssuingCATelecom

because IssuingCATelecom is the intermediate CA certificate, not the website certificate.

After selecting catalogo.personal.corp, go to:

Details > Thumbprint

Then compare that Thumbprint with the Certificate Hash from netsh:

4b0304ce561921f4f40a81e3a149c29f45029cfd

Chrome may show the Thumbprint with spaces or uppercase letters. That is okay. You can remove the spaces and compare only the characters.

For example, these two values are the same:

4B 03 04 CE 56 19 21 F4 F4 0A 81 E3 A1 49 C2 9F 45 02 9C FD

4b0304ce561921f4f40a81e3a149c29f45029cfd

If the Thumbprint matches the netsh Certificate Hash, then Chrome is receiving the same certificate used by the IIS/HTTP.sys binding.

If the Thumbprint does not match, then Chrome is receiving a different certificate.
Lucas Peñaloza 536 Reputation points

2026-05-26T15:21:31.1066667+00:00

Hi Tom,

Don't worry!!!.

So,

In Chrome:

But Thumbprint field does not appear!!!.

This field should appear????.

Thanks again for your support.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-05-27T10:34:16.3566667+00:00
Hi @Lucas Peñaloza ,

Thank you for checking this.

The value shown in your screenshot is the Serial Number. That is not the value to compare with the Certificate Hash from netsh.

For this check, please compare the Certificate Hash with the certificate Thumbprint. In Chrome, this may also be shown as SHA-1 Fingerprint.

It looks like you selected the correct certificate:

catalogo.personal.corp

Please stay on that certificate, scroll further down in the Details list, and look for either:

Thumbprint

SHA-1 Fingerprint

Then compare that value with:

4b0304ce561921f4f40a81e3a149c29f45029cfd

Please do not compare the Certificate Hash with the Serial Number.

If the browser does not show the Thumbprint or SHA-1 Fingerprint field, you can also export/open the certificate in the Windows Certificate Viewer, then go to Details > Thumbprint.
Lucas Peñaloza 536 Reputation points

2026-05-28T20:28:29.9066667+00:00

Hi Tom,

So;

This will be the information we need???.Thank you for your help.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-05-29T02:58:24.4533333+00:00
Hi @Lucas Peñaloza ,

This is close, but it is still not the value we need.

The value in your screenshot is SHA-256 Fingerprint. For this check, we only need the SHA-1 Thumbprint of the website certificate.

Please:

In the certificate window, select: catalogo.personal.corp

Look for:

Thumbprint
or

SHA-1 Fingerprint

Please do not use:

Serial Number

SHA-256 Fingerprint

Then compare it with this value from the server:

4b0304ce561921f4f40a81e3a149c29f45029cfd

If you cannot find Thumbprint or SHA-1 Fingerprint in the browser, please export the certificate and open it in Windows Certificate Viewer, then check:

Details > Thumbprint
Lucas Peñaloza 536 Reputation points

2026-06-01T14:41:53.02+00:00

Ho Tom,

We were looking for that field and it doesn't appear in the Certificate, at least not the one shown by the Browser!!!!

But, it seems to us that the browser is taking the value of: Personal - Certificates!!!!.

In other words, this certificate:

But, I should be getting the certificate from: Intermedate Certification Authorities,

Are we correct?

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

2026-06-02T02:41:32.2533333+00:00
Hi @Lucas Peñaloza ,

Thank you for checking this.

No, the website certificate should not come from Intermediate Certification Authorities.

For IIS, please check only this location:

Certificates (Local Computer) > Personal > Certificates

The Intermediate Certification Authorities store is only for the certificate chain, not for selecting the website certificate.

To confirm which certificate IIS is using, please run this PowerShell command on the IIS server:

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, NotAfter, Thumbprint

In the result, please look for this thumbprint:

4B0304CE561921F4F40A81E3A149C29F45029CFD

This is the certificate hash shown by:

netsh http show sslcert

If you find the same thumbprint in the PowerShell result, that is the certificate currently used by the HTTPS binding.

If you do not find that thumbprint, then IIS/HTTP.sys is not using the certificate you are currently selecting in IIS Manager.

For now, we only need to confirm whether this thumbprint exists under Personal > Certificates.
Lucas Peñaloza 536 Reputation points

2026-06-02T16:03:18.7733333+00:00

HI Tom,

Look,

We are in the Virtual Machine with the IIS!!!.

Now, the certificates!!!.

That we found in the:

Personal - Certificates.

But,

We found the same certificate in:

In other words, the same certificate is implemented in both!!!!.

Personal - Certificates and Intermedate Certification Authorities.

The powershell command:

PS C:> Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, NotAfter, Thumbprint

Subject

CN=IssuingCAGrupoTelecom, DC=telecom, DC=arg, DC=telecom, DC=com, DC=ar

E=******@teco.com.ar, CN=catalogo.personal.corp, OU=Ciberseguridad, O=Telecom Argentina S.A., L=Ciudad ...

CN=RootCAGrupoTelecom

CN=catalogo.personal.corp, OU=Ciberseguidad, O=Telecom Group, L=Buenos Aires, S=CABA, C=AR

On the other hand, we were looking to see if we could obtain the Certificate and we found it.

Look!!!.

C:\Temp\Certificados Lasts\catalogo.personal.corp.zip

Is it useful to have the implemented certificate?

Thank you for your help!!!.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-03T03:10:25.8433333+00:00
Hi @Lucas Peñaloza ,

Thank you for the screenshots.

I can see the same certificate appears in both places. For this check, please ignore Intermediate Certification Authorities for now and focus only on the certificate in Personal > Certificates.

To check which certificate IIS is actually using, please run this command on the IIS server:

Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq "4B0304CE561921F4F40A81E3A149C29F45029CFD"}

This will check whether the certificate from the HTTPS binding exists in Personal.

Please send me what the command returns. If nothing is returned, please let me know that as well.
Lucas Peñaloza 536 Reputation points

2026-06-03T17:47:38.35+00:00

Tom,

OK,

So, We have;

PS C:> Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq "4B0304CE561921F4F40A81E3A149C29F45029CFD"}

PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint Subject

4B0304CE561921F4F40A81E3A149C29F45029CFD CN=catalogo.personal.corp, OU=Ciberseguidad, O=Telecom Group, L=Buenos Air...

That's what the command returns!!!!.

This is useful for analysis???.

Thank you for your help!!!.
Lucas Peñaloza 536 Reputation points

2026-06-09T15:01:40.99+00:00

Hi Tom,

Any news regarding this topic?

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

2026-06-10T03:53:36.0066667+00:00
Hi @Lucas Peñaloza ,

I'm so sorry for the late response.

Thank you, yes, this result is useful.

It confirms that the certificate used by the HTTPS binding exists in Personal > Certificates.

Now please check whether this same certificate contains the website name in Subject Alternative Name.

Please run this command on the IIS server:

$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq "4B0304CE561921F4F40A81E3A149C29F45029CFD"} $cert.Extensions | Where-Object {$_.Oid.Value -eq "2.5.29.17"} | ForEach-Object {$_.Format($true)}

Please check whether the output includes:

DNS Name=befancatalogo.personal.corp

If it appears there, the certificate contains the correct website name. If it does not appear, then the certificate needs to be reissued with befancatalogo.personal.corp in the Subject Alternative Name field.
Lucas Peñaloza 536 Reputation points

2026-06-16T20:23:21.51+00:00

Hi Tom,

We executed the command and it didn't return anything!!!.

Look;

What else can we verify?.

Thank you for your help!!!!.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-17T02:38:19.7633333+00:00
Hi @Lucas Peñaloza ,

Thank you, this result is useful.

Since the command did not return anything, this means the certificate being used now does not have a Subject Alternative Name (SAN).

Your website is opened with this name:

befancatalogo.personal.corp

So the certificate must also contain this name in SAN:

DNS Name=befancatalogo.personal.corp

The next step is to request a new certificate with this SAN name:

DNS Name=befancatalogo.personal.corp

If users also open the site with this name:

catalogo.personal.corp

then include both names in the new certificate:

DNS Name=befancatalogo.personal.corp

DNS Name=catalogo.personal.corp

After you receive the new certificate:

Install it in Personal > Certificates

Select it in the IIS HTTPS binding

Run this command again:

netsh http show sslcert

Test the site again in the browser

You do not need to use the certificate from the Intermediate store for the website. The website certificate should be installed and selected from Personal > Certificates.
Lucas Peñaloza 536 Reputation points

2026-06-17T18:09:01.71+00:00

Tom,

So,

Thanks to your help, we have confirmed that the Certificate does not work!!!.

But what kind of certificate should we request?

Root o Intermediary???.

Thank you for your help!!!!.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-18T02:47:46.5966667+00:00
Hi @Lucas Peñaloza ,

Thanks for sharing the update.

You do not need to request a Root certificate or an Intermediate certificate for the IIS website.

For this site, you need to request a server certificate / SSL/TLS certificate for the website. The Root and Intermediate certificates are only used to build the trust chain. They are not the certificate that should be selected in the IIS HTTPS binding.

When requesting the new certificate from your certificate/PKI team, please ask them to include this name in the Subject Alternative Name (SAN) field:

DNS Name=befancatalogo.personal.corp

If users also access the site with this name, include it as well:

DNS Name=catalogo.personal.corp

After you receive the new certificate, please make sure it is installed with its private key under:

Certificates (Local Computer) > Personal > Certificates

Then select that new certificate in the IIS HTTPS binding for the website.

So the main point is: request a new server SSL/TLS certificate with befancatalogo.personal.corp in SAN, install it under Personal > Certificates, and bind it to the IIS site.
Lucas Peñaloza 536 Reputation points

2026-06-19T16:22:52.6933333+00:00

HI Tom,

We now need to figure out how to approach this issue with the Information Security department. Dealing with Information Security is not easy.

We will be in touch to see if we can finally resolve this issue.

Since the problem continues.

Thank you for your help!!!!.
Lucas Peñaloza 536 Reputation points

2026-06-26T20:22:05.3466667+00:00

Hi Tom,

We were verifying the virtual machines involved in the Solution!!!.

We have several virtual machines, with IIS.

And in one of the virtual machines, we found:

We understand that the Certificate Name is irrelevant!!!.

Is the same, catalogo.personal.corp.102021 or catalogo.personal.corp.New no?

But, this Certificate, is expired!!!.

Look

But what is it that has expired?.

If the Date is displayed as valid!!!!.

The chain may be broken???.

Thank you so much for your help!!!.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-29T09:02:26.5066667+00:00
Hi @Lucas Peñaloza ,

Sorry for the delayed response.

Yes, the certificate name shown in IIS, such as catalogo.personal.corp.102021 or catalogo.personal.corp.New, is only a friendly name. It is just a label to help identify the certificate in IIS/Windows.

However, the actual certificate selected in the HTTPS binding still matters.

From your latest screenshot, this IIS server appears to be using an older certificate, and Windows is showing that certificate as expired or not yet valid. The date may look valid depending on how it is read, but Windows is already treating that certificate as invalid.

Please replace the certificate in the HTTPS binding on this IIS server with the new server SSL/TLS certificate that contains:

DNS Name=befancatalogo.personal.corp

in the Subject Alternative Name (SAN) field.

Since you mentioned there are several virtual machines with IIS, please check the HTTPS binding on each IIS VM involved in this solution. If even one VM is still using an old or expired certificate, users may still see the certificate error when their request reaches that VM.

So the next step is to make sure every IIS VM is using a valid server certificate for befancatalogo.personal.corp, installed under:

Certificates (Local Computer) > Personal > Certificates

and selected in the IIS HTTPS binding.
Lucas Peñaloza 536 Reputation points

2026-06-30T00:23:36.2133333+00:00

Hi Tom;

Based on the screenshots, the certificate chain is broken, right???.

Thank you for your help!!!.
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-30T03:11:08.6866667+00:00
Hi @Lucas Peñaloza ,

Not exactly. Based on the screenshots, this is an expired certificate, not a broken chain. These are two different things:

Expired certificate: the "Valid to" date has already passed. This is what your screenshots are showing ("This certificate has expired or is not yet valid").

Broken chain: the issuing/root CA cannot be trusted or cannot be found. This shows up in the Certification Path tab, usually with a red mark on one of the CA certificates.

If there is no red mark and it says "This certificate is OK", then the chain does not appear to be the issue, and the expiry is the main issue shown in your screenshots.

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: