ProFTPD and OCSP stapling

Server
1

Hi there,
I am using LetsEncrypt successfully for my web and ftp server under firefox.allowed.org – and I recently added OCSP stapling to my certificates and to my webserver. On the webserver front, everything works as expected. But my ProFTPD has problems with the OCSP.
https://ftptest.net/ says:

Status: Resolving address of firefox.allowed.org
Status: Connecting to 46.5.180.138
Warning: The entered address does not resolve to an IPv6 address.
Status: Connected, waiting for welcome message...
Reply: 220 ::ffff:192.168.178.37 FTP server ready
Command: CLNT https://ftptest.net on behalf of 2a02:8071:b186:cd00:e1c0:2f29:6c9d:b299
Reply: 550 SSL/TLS required on the control channel
Command: AUTH TLS
Reply: 234 AUTH TLS successful
Status: Performing TLS handshake...
Status: TLS handshake successful, verifying certificate...
Status: Received 2 certificates from server.
Status: cert[0]: subject='CN=firefox.allowed.org' issuer='C=US,O=Let\27s Encrypt,CN=Let\27s Encrypt Authority X3'
Status: cert[1]: subject='C=US,O=Let\27s Encrypt,CN=Let\27s Encrypt Authority X3' issuer='O=Digital Signature Trust Co.,CN=DST Root CA X3'
Error: Certificate verification failed: The certificate is NOT trusted. The received OCSP status response is invalid.

I am using ProFTPD 1.3.6 and have the following configuration (for TLS)

TLSEngine on
TLSLog .../tls.log
TLSProtocol TLSv1.2
TLSRSACertificateFile .../firefox.allowed.org/cert.pem
TLSCertificateChainFile .../firefox.allowed.org/fullchain.pem
TLSRSACertificateKeyFile .../firefox.allowed.org/privkey.pem
TLSVerifyClient off
TLSRequired on
TLSOptions NoSessionReuseRequired
TLSDHParamFile .../dhparams.pem
TLSCipherSuite "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA:DHE-RSA-AES256-SHA2$
TLSRenegotiate ctrl 1500 data 512000 timeout 300
TLSSessionCache internal: 1800
TLSStapling on
TLSStaplingResponder http://ocsp.int-x3.letsencrypt.org/
TLSStaplingOptions NoNonce

I am not sure what the issue really is. The whole TLS handshake looks normal (the other side closes connection after realising that the OCSP response is unsuccessful). Has someone already used OCSP stapling with ProFTPD and/or could point me in the right direction?

3

For 1: I can validate my webservers response fine, and it runs on the same system (you can just try to access https://firefox.allowed.org).
For 2: They are the same files that are used by the webserver and they are actually the ones on this system.

I clarified my post above: the first output is from a remote client and shows what happens if someone tries to connect.
But you are right, I should try to fix the local / remote IP issue at some point.

Edit: There is only one cert.pem, fullchain.pem, privkey.pem on the system that provides firefox.allowed.org (both web and ftp server)

4

Will it work without:
TLSStapling on
TLSStaplingResponder http://ocsp.int-x3.letsencrypt.org/
TLSStaplingOptions NoNonce

Have you looked into adding:
TLSStaplingCache

5

No to both of them.
Without

TLSStapling on

the error states that the certificate requires stapling (as it should) and no connection can be made.

The options

TLSStaplingResponder http://ocsp.int-x3.letsencrypt.org/
TLSStaplingOptions NoNonce

are not necessary, but I tried anyways to see if it would help.

But TLSStaplingCache is described as being optional and it seems difficult to set up (I would need to manually compile proftpd instead of using the Gentoo ebuild).

If I manually check the certificates, they seem to work. For the webserver:

openssl s_client -servername firefox.allowed.org -connect firefox.allowed.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > cert.pem
openssl s_client -servername firefox.allowed.org -connect firefox.allowed.org:443 -showcerts 2>&1 < /dev/null | sed -n '/1 s:\/C=US\/O=Let'\''s Encrypt\/CN=Let'\''s Encrypt Authority X3/,/-----END/p' | sed -n '/-----BEGIN/,/-----END/p'> chain.pem
openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -url http://ocsp.int-x3.letsencrypt.org/ -header "HOST" "ocsp.int-x3.letsencrypt.org" -text

For the FTP server

openssl s_client -starttls ftp -servername firefox.allowed.org -connect firefox.allowed.org:21 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > cert.pem
openssl s_client -starttls ftp -servername firefox.allowed.org -connect firefox.allowed.org:21 -showcerts 2>&1 < /dev/null | sed -n '/1 s:\/C=US\/O=Let'\''s Encrypt\/CN=Let'\''s Encrypt Authority X3/,/-----END/p' | sed -n '/-----BEGIN/,/-----END/p'> chain.pem
openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -url http://ocsp.int-x3.letsencrypt.org/ -text -header "HOST" "ocsp.int-x3.letsencrypt.org"

Both responses succeed (if you give additional -verify_other with the full chain)

6

So this fails?

TLSStapling OFF
(rem/hash) TLSStaplingResponder http://ocsp.int-x3.letsencrypt.org/
(rem/hash) TLSStaplingOptions NoNonce

7

Yes. If I do this, restart ProFTPD and test again I get

Status: Resolving address of firefox.allowed.org
Status: Connecting to 46.5.180.138
Warning: The entered address does not resolve to an IPv6 address.
Status: Connected, waiting for welcome message...
Reply: 220 ::ffff:192.168.178.37 FTP server ready
Command: CLNT https://ftptest.net on behalf of 132.230.166.183
Reply: 550 SSL/TLS required on the control channel
Command: AUTH TLS
Reply: 234 AUTH TLS successful
Status: Performing TLS handshake...
Status: TLS handshake successful, verifying certificate...
Status: Received 2 certificates from server.
Status: cert[0]: subject='CN=firefox.allowed.org' issuer='C=US,O=Let\27s Encrypt,CN=Let\27s Encrypt Authority X3'
Status: cert[1]: subject='C=US,O=Let\27s Encrypt,CN=Let\27s Encrypt Authority X3' issuer='O=Digital Signature Trust Co.,CN=DST Root CA X3'
Error: Certificate verification failed: The certificate is NOT trusted. The certificate requires the server to include an OCSP status in its response, but the OCSP status is missing.
8

Try:
TLSStapling ON
TLSStaplingResponder http://ocsp.int-x3.letsencrypt.org/
(rem/hash) TLSStaplingOptions NoNonce

9

Sure (I already did that). The result is then

....
Error: Certificate verification failed: The certificate is NOT trusted. The received OCSP status response is invalid.
10

I’m thinking it’s not being allowed enough time to get the response, or can’t get the response.
Is this “http://ocsp.int-x3.letsencrypt.org/” blocked out from your FTP server?

Or maybe have to use:
TLSStaplingCache
to have OCSP answer ready…

11

The only thing I havent tried is the TLSStaplingCache. I already tried TLSStaplingTimeout 300 and the resolver is reachable from my machine (the openssl commands above checked that; both on my machine and from a machine on another network).

12

Ok, I now tried with TLSStaplingCache shm:/file=...; this did not change anything (but it works insofar as that the cache is created).

I manually added Lets Encrypt root certificate to the chain. ftptest picks this up, but it does not change anything:

Status: cert[0]: subject='CN=firefox.allowed.org' issuer='C=US,O=Let\27s Encrypt,CN=Let\27s Encrypt Authority X3'
Status: cert[1]: subject='C=US,O=Let\27s Encrypt,CN=Let\27s Encrypt Authority X3' issuer='O=Digital Signature Trust Co.,CN=DST Root CA X3'
Status: cert[2]: subject='O=Digital Signature Trust Co.,CN=DST Root CA X3' issuer='O=Digital Signature Trust Co.,CN=DST Root CA X3'
Error: Certificate verification failed: The certificate is NOT trusted. The received OCSP status response is invalid.

I checked whether ftptest validates the chain by swapping certificates, and indeed it reports that the certs are presented out of order.

I also tried Filezilla, which gives a cryptic error message (Received certificate chain could not be verified. Verification status is 1048576.) that is referenced in this forum post as related to OCSP.

With lftp I can connect to the server, but I am not sure if lftp simply ignores OCSP; at least I could not find anything about OCSP being a supported feature.

I have cross-posted this issue in the proftpd forums.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.