Issue to FTP SSL

Question

Issue to FTP SSL

Jonathan 480

Hi,

How to resolve it below regarding FTP SSL?

User's image

0 comments

2 answers

Your answer

Answer 1

Configure IIS FTP to use a trusted server certificate whose Subject Alternative Name matches the FileZilla host, ensure its issuing chain is installed, and then reconnect using explicit FTPS on port 21.

Correct the IIS FTPS certificate

On the FTP server, open Internet Information Services (IIS) Manager.
Expand server name → Sites, and select the FTP site.
Open FTP SSL Settings.
Under SSL Certificate, select the intended server certificate.
Select Require SSL connections if all clients must use FTPS, then click Apply. IIS supports explicit FTPS on port 21; port 990 is for implicit FTPS.^1^

Do not select a certificate merely because it appears in the list. Open it and verify:

It is currently valid.
It includes Server Authentication usage.
Its Subject Alternative Name (SAN) contains the exact DNS name entered in FileZilla, such as ftp.example.com.
It has an associated private key.
It chains to a trusted root without errors.

If FileZilla connects by IP address while the certificate covers only a DNS name, change FileZilla to use that DNS name. A different hostname requires a replacement certificate containing that name in its SAN.

Repair the certificate chain

The dialog shows only one certificate in the chain. Check whether the required intermediate CA certificate is missing:

On the IIS server, run certlm.msc.
Check these Local Computer stores:
- Personal → Certificates: FTP server certificate with its private key.
- Intermediate Certification Authorities → Certificates: intermediate CA certificate(s).
- Trusted Root Certification Authorities → Certificates: trusted root CA.
Open the server certificate and inspect Certification Path.
If the path is incomplete or has an error, obtain the correct intermediate certificate bundle from the certificate authority and install each intermediate under Intermediate Certification Authorities.
Reopen FTP SSL Settings, reselect the certificate if necessary, click Apply, and restart the FTP site.

Microsoft recommends following the issuing CA’s guidance to install the certificate and choose the most compatible chain when multiple chains are available.^2^

If the certificate shows CERT_E_UNTRUSTEDROOT (0x800b0109), the chain terminates at a root that is not trusted. Also verify that Server Authentication appears in the certificate’s intended purposes.^3^

Configure FileZilla consistently

In FileZilla → Site Manager, use:

Host: the DNS name covered by the certificate SAN.
Port: 21.
Protocol: FTP – File Transfer Protocol.
Encryption: Require explicit FTP over TLS.

When the warning reappears, compare the displayed SHA-256 fingerprint with the fingerprint obtained directly from the server certificate:

On the server, open certlm.msc.
Open the bound server certificate.
Select Details → Thumbprint.
Compare it through a trusted administrative channel.

Only select Always trust this certificate in future sessions after the hostname, validity, issuer, and fingerprint have been verified. That option stores an exception in that FileZilla client; it does not repair an incorrect IIS binding or incomplete certificate chain.

For an internally issued or self-signed certificate, every client must trust the organization’s root CA. For an Internet-facing service used by unmanaged clients, a certificate from a broadly trusted public CA avoids distributing an internal root certificate.

References

Answer 2

Daphne Huynh (WICLOUD CORPORATION) 2,540 Microsoft External Staff Moderator

Welcome to Microsoft Q&A!

Thank you for taking the time to provide the details and screenshot.

Based on the information provided, the message “The server’s certificate is unknown” means that the FTP client was able to reach the FTPS server and receive its SSL/TLS certificate, but the client could not establish a trusted certificate chain for that certificate.

Therefore, this warning points primarily to certificate validation/trust, rather than indicating by itself that FTP port 21/990 or the passive FTP ports are blocked.

The most likely cause is that the FTP client cannot validate the certificate presented by the FTPS server back to a trusted root Certificate Authority (CA).

This can happen when:

A required intermediate CA certificate is missing or not configured correctly on the server.
The root CA is not trusted on the client computer.
The hostname used for the FTPS connection does not match the certificate's Common Name (CN) or Subject Alternative Name (SAN).
The certificate is expired or otherwise no longer valid.

The “Trust this server and carry on connecting?” prompt only allows the client to proceed by trusting the presented certificate. It does not, by itself, confirm that the certificate or certificate chain is valid.

I would like to recommend correcting the certificate trust chain on the FTPS server rather than permanently accepting the unknown certificate in the FTP client.

On the FTP server, please verify that:

The FTPS service is using the intended server certificate.
The certificate is valid and has not expired.
The DNS hostname used by the FTP client matches one of the names in the certificate's CN or SAN.
The server certificate and any required intermediate CA certificates form a valid chain to a root CA that is trusted by the client.

If the FTP service is hosted in IIS, you can verify the certificate assigned to the FTP site under:

IIS Manager > FTP site > FTP SSL Settings

Please avoid selecting “Always trust this certificate in future sessions” simply to suppress the warning unless you have independently verified the certificate's fingerprint with the FTP server administrator. Permanently accepting the certificate without verifying it could bypass an underlying certificate validation problem.

Moreover, after correcting the server certificate and certificate chain, reconnect using the DNS hostname included in the certificate, rather than an IP address or another alias.

If the certificate and trust chain are configured correctly, the FTP client should be able to validate the server certificate without displaying the Unknown certificate warning.

If the warning continues, compare the SHA-256 fingerprint shown by the FTP client with the certificate fingerprint provided independently by the FTP server administrator. If the fingerprints do not match, do not trust or accept the certificate.

I hope this helps clarify why the warning appears and provides a safe path to resolve the certificate trust issue.

References:

FTP over SSL configuration in IIS

Using FTP over SSL in IIS

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Jonathan 480 Reputation points

2026-10-30T04:35:33.82+00:00

Thanks a lot. Within FTP SSL settings, I only have this beloow. Do not have "Always trust this certificate in future sessions” to select.
Daphne Huynh (WICLOUD CORPORATION) 2,540 Reputation points Microsoft External Staff Moderator

2026-10-30T05:33:57.1633333+00:00
Thank you for the additional screenshot. This helps clarify the situation.

The “Always trust this certificate in future sessions” option is not part of IIS FTP SSL Settings. That option is displayed by the FTP client when the client receives a certificate that it cannot validate as trusted. Therefore, it is expected that you will not find this checkbox in IIS Manager.

From the screenshot, your IIS FTP site already has an SSL certificate selected under FTP SSL Settings. This is the IIS-side configuration that determines which certificate the FTP service presents to clients when establishing an FTPS connection.

The Unknown certificate warning in your original screenshot is generated on the client side after the certificate has been received. In other words, IIS can present a certificate successfully, while the FTP client can still warn that the certificate cannot be trusted.

At this point, I recommend validating the certificate that IIS is actually presenting.

In IIS Manager > Sites > MYFTP > FTP SSL Settings, select View... next to the certificate currently selected.

Please check the following certificate properties:

On the General tab, confirm that the certificate is within its validity period.

On the Details tab, confirm that the DNS hostname used for the FTPS connection is covered by the certificate name or Subject Alternative Name (SAN).

On the Certification Path tab, confirm that Windows can build the certificate chain successfully to a trusted root CA and does not report a certificate validation error.

If the Certification Path reports that the issuing CA cannot be found or trusted, the certificate chain needs to be corrected. Make sure the required intermediate CA certificates are installed correctly and that the intended server certificate remains selected under FTP SSL Settings.

After correcting any certificate-chain issue, reconnect from the FTP client using the DNS hostname covered by the certificate.

Moreover, if the Unknown certificate warning still appears, compare the SHA-256 fingerprint displayed in the FTP client's warning with the fingerprint of the certificate displayed through View... in IIS.

If the fingerprints match, this confirms that the FTP client is receiving the certificate currently configured in IIS. If the certificate chain is also valid on the server but the FTP client still considers the certificate unknown, the next investigation needs to focus on how that FTP client validates certificates and which certificate trust store it uses.

If the fingerprints do not match, please do not select a permanent trust option in the FTP client. A mismatch means that the certificate reaching the client is different from the certificate being reviewed in IIS. In that situation, the connection path would need further investigation to determine where the different certificate is being presented.

Microsoft Q&A is primarily a community-based forum, can help review the documented IIS configuration and recommend troubleshooting steps. However, the forum does not provide the same access to your environment that a support engineer would have, such as collecting and analyzing server-side diagnostics, reviewing the complete certificate store and certificate chain, tracing the TLS/FTPS handshake, or investigating network devices that may sit between the FTP client and IIS.

The “Always trust this certificate in future sessions” dialog itself also comes from the FTP client rather than IIS. If IIS presents the expected certificate and Windows shows a valid certificate chain, but that particular FTP client continues to reject or distrust the certificate, the remaining behavior is client-specific. In that case, please check the FTP client's documentation or contact the FTP client vendor to determine which certificate store the application uses and why it does not trust the certificate.

If the evidence instead points to IIS or Windows Server continuing to present an incorrect certificate, and the issue requires logs or environment-specific investigation beyond what can reasonably be reviewed through Q&A, the appropriate Microsoft next step would be to open a Microsoft Support case. Microsoft Support can work directly with the affected environment and collect the diagnostic information needed for deeper IIS/FTPS troubleshooting.

For now, I recommend completing the View certificate > Certification Path > SHA-256 fingerprint validation above first. That will establish whether the issue remains with the IIS certificate configuration or whether the investigation needs to move to the FTP client or the connection path.

I hope this clarifies both why you do not see the Always trust setting in IIS and what should be checked next.
Jonathan 480 Reputation points

2026-10-30T09:32:57.9733333+00:00

Thanks a lot. How to choose this red one

below?
Daphne Huynh (WICLOUD CORPORATION) 2,540 Reputation points Microsoft External Staff Moderator

2026-10-31T03:18:51.7066667+00:00
Thank you for the screenshot.

Yes, I can clarify this to help you.

You do not need to choose one of the certificate folders in certlm.msc first.

From your IIS screenshot, the FTP site MYFTP already has a certificate selected in FTP SSL Settings, and the certificate currently shown is 1028 FTP SSL. The important point is to inspect that exact certificate rather than selecting a certificate manually from one of the many stores shown in certlm.msc.

In IIS Manager > Sites > MYFTP > FTP SSL Settings, the SSL Certificate field identifies the certificate configured for this FTP site.

Therefore, when the earlier instruction says "Open the bound server certificate," it means the certificate currently selected in this SSL Certificate field.

In your screenshot, that appears to be: 1028 FTP SSL

The IIS FTP SSL configuration specifies the certificate used for SSL/TLS by the FTP service.

The confusion is understandable because certlm.msc initially displays many certificate stores, such as Personal, Trusted Root Certification Authorities, and Intermediate Certification Authorities.

You should not select one of those stores at random. The objective is first to identify and inspect the same certificate that IIS has configured for the FTP site.

Please use the following single method:

In IIS Manager > Sites > MYFTP > FTP SSL Settings, leave 1028 FTP SSL selected.

Select View... beside the SSL Certificate field.

In the certificate window, select the Details tab.

Select Thumbprint and note the displayed certificate thumbprint.

Also select the Certification Path tab and confirm whether Windows reports that the certificate chain is valid.

This is preferable to manually looking through certlm.msc, because View... starts with the certificate that IIS is currently configured to use.

If you specifically need to locate the same certificate later in certlm.msc, you can use the certificate details obtained from View..., such as the certificate name and thumbprint, to identify the matching certificate. The server certificate would normally be looked for in the local computer certificate store, but the IIS View... method removes the need to guess which certificate is the correct one.

After obtaining the thumbprint from View..., reconnect from the FTP client until the Unknown certificate warning appears and compare the fingerprint/certificate information displayed by the FTP client with the certificate you just viewed in IIS.

If they match, that confirms that the FTP client is receiving the certificate configured for the IIS FTP site. The next check is then whether the Certification Path is trusted and whether the hostname used by the FTP client is covered by the certificate.

If they do not match, do not permanently trust the certificate in the FTP client. That would indicate that a different certificate is reaching the client and the connection path would need further investigation.

So, for your current screenshot, please do not choose a certificate folder in certlm.msc yet. Start with IIS Manager > MYFTP > FTP SSL Settings > 1028 FTP SSL > View... > Details > Thumbprint and let us know whether the certificate shown there matches the one presented by the FTP client.
Jonathan 480 Reputation points

2026-10-31T13:59:21.0933333+00:00

How to further check it below?

Status: Initializing TLS...

Status: TLS connection established.

Command: USER xxxwong

Response: 530 Valid hostname is expected.

Error: Could not connect to server

since Namecheap asked to omit the SSL certificate issue.
Jonathan 480 Reputation points

2026-11-02T09:59:23.2233333+00:00

Any help?
Daphne Huynh (WICLOUD CORPORATION) 2,540 Reputation points Microsoft External Staff Moderator

2026-11-03T01:39:46.91+00:00
Thank you for sharing the latest connection log.

The following entries are particularly important:

Status: TLS connection established.

Response: 530 Valid hostname is expected.

The first message indicates that the client was able to reach the FTP server and establish the TLS connection successfully. This means the earlier certificate warning is no longer the immediate issue preventing the connection.

The current failure occurs afterward, when IIS processes the FTP connection. Microsoft documents an IIS FTP substatus specifically for situations where the hostname does not match a configured FTP site. For this reason, the next step should be to verify that the hostname used by the FTP client matches the hostname configured for the IIS FTP site.

Please perform the following check:

Open IIS Manager on the FTP server.

In the Connections pane, expand Sites and select MYFTP.

In the Actions pane, select Bindings.

Check the hostname configured for the FTP binding.

In the FTP client, make sure the Host field uses that exact DNS hostname rather than the server's IP address or a different alias.

Confirm that the hostname resolves to the correct FTP server and is covered by the SSL certificate's certificate name or Subject Alternative Name (SAN).

After confirming that the hostname is consistent, restart the FTP site and test the connection again.

If this is the cause, the server should no longer return:530 Valid hostname is expected.

The connection should instead continue to the next authentication step after the USER command.

I would not recommend removing or changing the FTP hostname binding simply to test the connection unless you have first confirmed the impact on the server. If multiple FTP sites are configured on the same server, changing the binding may affect other FTP connections.

If the hostname entered in the FTP client already exactly matches the IIS FTP binding and the same 530 Valid hostname is expected response continues, I would recommend stopping troubleshooting through Q&A at that point and opening a Microsoft Support case.

I understand that you would like to continue checking the configuration here. However, further troubleshooting would require access to environment-specific information such as the complete FTP site bindings, IIS FTP logs, applicationHost.config, DNS configuration, FTP client settings, and potentially the FTP/TLS exchange. Those details cannot be reliably diagnosed through screenshots and individual configuration checks alone.

A Microsoft Support engineer can work directly with your environment, collect the required diagnostic information, and determine why IIS is not matching the hostname to the expected FTP site.

For this reason, this will be my final troubleshooting recommendation for this Q&A thread. Please complete the hostname validation above once. If the hostname already matches, or the 530 Valid hostname is expected error remains afterward, please open a Microsoft Support case rather than making additional changes to the IIS FTP or SSL configuration without further diagnostic evidence.

I hope the troubleshooting so far has helped narrow the issue down and clarify the appropriate next step.
Jonathan 480 Reputation points

2026-11-03T07:13:23.5933333+00:00

Yes, I checked the Host within Binding of MYFTP in IIS of the server is exactly same host name below. Why was the reason of the current issue?
Jonathan 480 Reputation points

2026-11-04T03:08:07.03+00:00

Any help?