• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Certificate is unknown (FTP)

In the "Betreff" section you can see that the name that the certificate secures is "moodymind.de". When you enter "dienetzwerft.de" as the hostname, it might resolve to the same IP address, but it is still a different domain name. Hence Filezilla let's you know that there is a mismatch between the domain name you are trying to contact and the domain name that is protected in your certificate.

For your FTP connection, use the server's name that is protected by an SSL certificate for exactly that server name.

However, for Filezilla you might still see a warning afterwards. On the first connection to the server Filezilla might ask you to confirm that you want to establish the connection despite the fact that server name and certificate content match. That is an expected behavior.
 
Hi Peter,

thank you. Yes, if i try to connect with moodymind.de the report say Server is unknown. Why did it work before? Dreamweaver is the same issue.

1635949807241.png
 
It only says that the certificate is unknown. It does not say that it is invalid or does not match the server name. This is a security warning only. You can check "Diesem Zertifikat zukünftig immer vertrauen" ("Always trust this certificate") and click "OK" to avoid the same message for the same connection in the future.
 
yes, i know how to prevent the message, but that is not the right way, i need a solution because our Customers are going crazy if they see "oh the server is unknown" and call us. It worked before, but why?
 
Please open "Zertifikat in Kette" and check whether a certificate in the chain has expired. If so, it is probably the DST Root CA X3 certificate. This must be removed from your server, because it has expired on September 27th, 2021. Please see Resolved - Lets Encrypt root certificate expiration on 30 September 2021 for details.

In general, it is the expected behavior for Filezilla to display the "unknown certificate" dialog if this is the first time that the certificate chain that Filezilla obtains from the server is new or something changed in that chain. I have serious doubts that it worked before, because it's built into Filezilla to display that dialog. Your customers must have seen it before.
 
i deactivated the DST Root ca, but same error. it works shure before, because if i try to connect on adobe dreamweaver this appears:
1635955472316.png
and now i have to change this to no trust to make it work
1635955512609.png
 
"Das Serverzertifikat ist abgelaufen ..." is a pretty clear message, isn't it? When you open the website in a browser and visualize the SSL certificate chain, is it a fully valid chain?
 
Ja, wie finde ich das heraus? Geht um dienetzwerft.de (alle Webseiten auf dem Server) - im Browser wird es ja als sicher angezeigt.
 
Thera said:
Ja, wie finde ich das heraus? Geht um dienetzwerft.de (alle Webseiten auf dem Server) - im Browser wird es ja als sicher angezeigt.
Click to expand...
Bitte nicht die Protokolle & Ports durcheinanderbringen. ftp auf Port 21 wird von einem ganz anderen Programm bereitgestellt als https auf Port 443.

proftpd's config is in /etc/proftpd.conf and /etc/proftpd.d/.
Where did you enable TLS1.3?
 
I think the issue is with something weird with ProFTPD under Debian. I was able to reproduce an issue where the DST Root CA X3 has been deactivated and certificates re-generated and FTP service restarted, yet any FTP connection to that test server still presents the DST Root CA X3 certificate and and expiration warning of it - although this certificate is no longer available on the server in question. This seems to be the case in what @Thera describes. Debian is not my home operating system so I can't shake cause and solution out of my sleeve for that, but at least it's a start where to look.
 
One step further. I checked each certificate that is referenced in the ProFTPD configuration on the server and also compared the full chain pem file and its components to the current single .pem files. All is correct. ProFTPD has the correct certificates and chain, yet Filezilla for this one system reports a different certificate chain. So now the question is: Where does Filezilla take this outdated information from?
 
Had Filezilla connected to that server before?
If you have to add the certificate on first connect, it might save more than just the fingerprint ...
 
I did not pay attention to the certificate chain error, so I don't know what happened. At the moment I can only say that even when I explicitely set the correct root certificate in the tls.conf file of ProFTPD, the client is still showing the wrong cert. Gotta go for today, maybe continue another day to figure this one out.
 
Peter Debik said:
I did not pay attention to the certificate chain error, so I don't know what happened. At the moment I can only say that even when I explicitely set the correct root certificate in the tls.conf file of ProFTPD, the client is still showing the wrong cert. Gotta go for today, maybe continue another day to figure this one out.
Click to expand...
Peter, have you figured out the fix for the DST Root CA X3 expiry issue? I'm having same issue now, Feb 2022.
 
If you click "Certificate in Chain" and find that the Root certificate is DST Root CA X3 which expired on Sep 30, 2021, you are facing same issue as I was.

Here is how I solved the issue on my AWS Lightsail server, which is based on blueprint "Plesk Hosting Stack on Ubuntu":

A. On the server, I ran "sudo su" to be a root user

B. Since my FTP server is ProFTPD, I ran "cat /etc/proftd.conf" and find these lines:
TLSRSACertificateFile /opt/psa/admin/conf/httpsd.pem
TLSRSACertificateKeyFile /opt/psa/admin/conf/httpsd.pem
TLSCertificateChainFile /opt/psa/admin/conf/httpsd.pem

C. I ran "/opt/psa/admin/conf/httpsd.pem" to find following 5 parts:
  1. CSR
  2. Private Key
  3. Server Certificate (expiry 3 months. Issuer is R3)
  4. R3 certificate (valid from Sep 3, 2020 to Sep 15, 2025. Issuer is ISRG Root X1)
  5. ISRG Root X1 certificate (valid is Jan 20, 2021 to Sep 30, 2024. Issuer is DST Root CA X3)
D. I copied and decoded above 5. ISRG Root X1 certificate with online certificate decoder. I found out that it was a certificate issued by the expired (Sep 30, 2021) DST Root CA X 3 certificate. This is a wrong one and should be replaced by another self-issued ISRG Root X1 certificate which is valid from Jun 4 ,2015 to Jun 4, 2035.

E. I downloaded the self-issued ISRG Root X1 certificate from https://letsencrypt.org/certs/isrgrootx1.pem then replace above 5. ISRG Root X1 certificate in file /opt/psa/admin/conf/httpsd.pem

Now I run FileZilla Client to connect, I still get "Unknown certificate" alert. But the checkbox for "Always trust this certificate in future sessions" is enabled. I can check it to continue connection.

Hope it helps.plesk.png
 
You must log in or register to reply here.

Similar threads

D
Issue certificate of VPS host still used after SSL configuration for newly added domain
Replies
4
Views
1K
deepnpisgah
D
E
Issue TLS 1.2 and 1.3 only
Replies
2
Views
2K
Benemortasia
B
M
Issue FTP behind VPN - Connect it via Local IP
Replies
0
Views
2K
Mutate2546
M
B
Issue Webpages are no longer reachable after update from 17.8 to 18.0
Replies
0
Views
2K
Brovning
B
UnS3eN
Issue No FTP (proFTP) access after 17.8.11 upgrade
Replies
4
Views
3K
UnS3eN
UnS3eN
Back
Top