FileZilla Forums

I've set up a new FTP site in IIS 10. FTP services work perfectly when using insecure connections (FTP). When i enable SFTP, however, the FZ client can no longer connect to the IIS server. I get the exact same error message posted in this thread:

"Received certificate chain could not be verified. Verification status is 1048576."
viewtopic.php?f=2&t=45554&p=156233&hili ... 6.#p156233

The response in that thread is quite vague to me. I looked at the certificate chain on both the client and server, and they match. I have added all necessary Intermediary certs on both the client and server sides as well. When i google that error, almost nothing comes up. I'm at a loss. I've asked other admins in my department, and theyre stumped too. IIS logs are not showing anything conclusively.

Let me run through the chain of events that leads to this error:

1. IIS server is booted. SFTP is online w/ SSL Cert installed. IIS is requiring secure connections over either port 22 or 990. (any combination of ports in passive mode results in the same error.)
2. the very FIRST attempt to connect works! My FZ client session shows up in IIS under "FTP Current Sessions." That said, there's an error in the client when trying to list the contents of the shared folder on the FTP server.
3. Eventually the connection/session times out due to inactivity.
4. I try to connect again and immediately get that 1048576 error.

to summarize: Insecure FTP connections work fine. The 1st attempt to connect w/ TLS works correctly, albeit showing an error when trying to list the directory contents. Subsequent attempts to connect fail w/ error 1048576.

When i enable SFTP, however, the FZ client can no longer connect to the IIS server.

Of course not. IIS does not speak SFTP, it only speaks FTP and FTP over TLS (FTPS).

"Received certificate chain could not be verified. Verification status is 1048576."

1048576 is GNUTLS_CERT_INVALID_OCSP_STATUS.

This has nothing to do with the chain in question, but with the OCSP status the server has stapled to the handshake.

The first connection probably works only because the server by that point has not yet obtained any OCSP information from the CA's OCSP responder. By the time you do subsequent requests the server has obtained an OCSP response, stapling it to the handshake. Either the response itself is invalid, or the server somehow fails to staple it correctly.

botg wrote: ↑

2018-12-06 23:57

1048576 is GNUTLS_CERT_INVALID_OCSP_STATUS.

This has nothing to do with the chain in question, but with the OCSP status the server has stapled to the handshake.

The first connection probably works only because the server by that point has not yet obtained any OCSP information from the CA's OCSP responder. By the time you do subsequent requests the server has obtained an OCSP response, stapling it to the handshake. Either the response itself is invalid, or the server somehow fails to staple it correctly.

thanks for the reply. knowing nothing about OCSP, how does one go about fixing this, then?

I don't use IIS. Please consult your server manual.