about vsftpd-ssl server, server validate problem

Question

I use "openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem" on LINUX RedHat As 3.0 vsftp server.
I export client certifiate from vsftpd.pem using IE tools on windows XP.
but in my code,
ftp.getRootCertificateStore().importPEMFile("C:\\test2.pem");
ftp.setRemoteHost("192.168.0.64");
ftp.connect();
ftp.auth(SSLFTPClient.AUTH_TLS);

echo "Exception"com.enterprisedt.net.ftp.ssl.SSLFTPCertificateException: The signature of 'C=CN,ST=Axon,L=Axon,O=Axon,OU=Axon,CN=Axon' certificate does not match its issuer (use SSLFTPCertificateException.printCertificates to view certificates.)
...

why...

I can logon the vsftp server using Flash XP on window XP.

Answer 1

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=CN, ST=Axon, L=Axon, O=Axon, OU=Axon, CN=Axon
Validity
Not Before: May 11 08:19:52 2007 GMT
Not After : Jun 10 08:19:52 2007 GMT
Subject: C=CN, ST=Axon, L=Axon, O=Axon, OU=Axon, CN=Axon
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:bf:90:56:d0:e9:0b:08:f1:f8:29:4b:86:f6:88:
dd:9a:11:d0:60:7a:59:71:14:d8:1b:74:90:ad:f4:
3e:a4:43:f6:4e:e0:09:7e:14:24:9d:fb:7b:61:9b:
d3:b9:ea:7e:71:ff:1b:00:7c:e0:19:af:4d:61:05:
82:1b:44:66:b9:c2:66:14:70:14:99:a8:8b:99:73:
ca:88:24:1a:c1:04:a3:ff:19:82:4c:ae:c6:dc:bc:
44:3d:31:50:b3:90:e7:60:b8:86:72:64:43:ca:a5:
50:4e:f5:fb:ec:70:53:d3:ee:fe:b2:0b:c3:db:3b:
f8:40:79:38:81:cb:09:5c:09
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
A4:96:11:5D:55:C3:89:9C:FF:3F:1C:91:9B:A3:44:BA:7A:E8:38:BA
X509v3 Authority Key Identifier:
keyid:A4:96:11:5D:55:C3:89:9C:FF:3F:1C:91:9B:A3:44:BA:7A:E8:38:BA
DirName:/C=CN/ST=Axon/L=Axon/O=Axon/OU=Axon/CN=Axon
serial:00

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
8c:f1:63:8f:a9:9d:b6:f4:8f:a0:0a:b5:e6:f5:c0:fd:07:82:
d4:3d:a1:df:2f:8f:b6:54:a2:fd:37:96:98:a1:15:fb:83:64:
e8:00:14:4f:af:47:6a:69:dd:09:3a:a3:21:7c:09:c0:c3:93:
bb:19:c8:61:38:45:9f:3f:8b:fa:95:a9:a4:89:7b:a1:c5:1e:
d1:c1:c6:10:b2:14:94:1e:33:2d:89:65:fb:6a:a4:ab:9a:41:
dc:ed:f3:2d:50:e8:11:14:ae:10:e6:56:83:fc:37:f8:d4:d8:
07:b8:00:c8:17:61:5a:46:8b:b3:a0:cb:d4:25:90:3c:c7:a6:
a6:ab
-----BEGIN CERTIFICATE-----
MIIC2jCCAkOgAwIBAgIBADANBgkqhkiG9w0BAQQFADBYMQswCQYDVQQGEwJDTjEN
MAsGA1UECBMEQXhvbjENMAsGA1UEBxMEQXhvbjENMAsGA1UEChMEQXhvbjENMAsG
A1UECxMEQXhvbjENMAsGA1UEAxMEQXhvbjAeFw0wNzA1MTEwODE5NTJaFw0wNzA2
MTAwODE5NTJaMFgxCzAJBgNVBAYTAkNOMQ0wCwYDVQQIEwRBeG9uMQ0wCwYDVQQH
EwRBeG9uMQ0wCwYDVQQKEwRBeG9uMQ0wCwYDVQQLEwRBeG9uMQ0wCwYDVQQDEwRB
eG9uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/kFbQ6QsI8fgpS4b2iN2a
EdBgellxFNgbdJCt9D6kQ/ZO4Al+FCSd+3thm9O56n5x/xsAfOAZr01hBYIbRGa5
wmYUcBSZqIuZc8qIJBrBBKP/GYJMrsbcvEQ9MVCzkOdguIZyZEPKpVBO9fvscFPT
7v6yC8PbO/hAeTiBywlcCQIDAQABo4GzMIGwMB0GA1UdDgQWBBSklhFdVcOJnP8/
HJGbo0S6eug4ujCBgAYDVR0jBHkwd4AUpJYRXVXDiZz/PxyRm6NEunroOLqhXKRa
MFgxCzAJBgNVBAYTAkNOMQ0wCwYDVQQIEwRBeG9uMQ0wCwYDVQQHEwRBeG9uMQ0w
CwYDVQQKEwRBeG9uMQ0wCwYDVQQLEwRBeG9uMQ0wCwYDVQQDEwRBeG9uggEAMAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAjPFjj6mdtvSPoAq15vXA/QeC
1D2h3y+PtlSi/TeWmKEV+4Nk6AAUT69HamndCTqjIXwJwMOTuxnIYThFnz+L+pWp
pIl7ocUe0cHGELIUlB4zLYll+2qkq5pB3O3zLVDoERSuEOZWg/w3+NTYB7gAyBdh
WkaLs6DL1CWQPMempqs=
-----END CERTIFICATE-----

Answer 2

It's probable that the certificate that the server is sending doesn't match the one that you're importing. There's an easy way to find out if this is the case. SSLFTPCertificateException has a method called getCertificates(), which returns the certificate-chain that the server sends during the TLS handshake. You use the methods in SSLFTPCertificate to inspect the certificate or you can call SSLFTPCertificateException.printCertificates() to export them in PEM format. If you do the latter then you can use "openssl x509 -text" to inspect the certificate. If there are two or more certificates then you'll have to split them into separate files using a text-editor.

- Hans (EnterpriseDT)

Answer 3

Thanks for your reply.
If it doesn't want to check the server common name,how to do?
I write the common name like "Axon" when generating server certificate,and the client code as follows:

SSLFTPStandardValidator ftpvalidator=new SSLFTPStandardValidator("Axon");
ftp.setCustomValidator(ftpvalidator);
ftp.connect();
ftp.auth(SSLFTPClient.AUTH_TLS);

but it doesn't work...

Answer 4

Could you please post the stack-trace of the exception?

- Hans (EnterpriseDT)

Answer 5

Thanks for your reply, it seems that code:

ftp.setCustomValidator(new SSLFTPStandardValidator("Axon"));
ftp.connect();
ftp.auth(SSLFTPClient.AUTH_TLS);

doesn't work.

com.enterprisedt.net.ftp.ssl.SSLFTPCertificateException: The signature of 'C=CN,ST=Axon,L=Axon,O=Axon,OU=Axon,CN=Axon' certificate does not match its issuer (use SSLFTPCertificateException.printCertificates to view certificates.)
   at com.enterprisedt.net.ftp.ssl.SSLFTPControlSocket.E(Unknown Source)
   at com.enterprisedt.net.ftp.ssl.SSLFTPClient.auth(Unknown Source)
   at pacsnode.Test.main(Test.java:53)

Answer 6

This error is coming from the bowels of Windows Crypto, which is reporting that the signature of one of the certificates being passed by the server is invalid. The actual windows error-code is TRUST_E_CERT_SIGNATURE. I have never seen this error before and have not yet managed to find much useful information about it. The obvious explanation is that one of the certificates being passed by the server is invalid. Could you please check them all out carefully and, if possible, try new ones.

- Hans Andersen (EnterpriseDT)