1

After a server change, I get nasty SSL warning in browsers (tested FF & Chrome), when loading an applet, used in an JavaEE Application (Serlvet API 3) The warning says: "Certificate is not valid, and cannot used to identify the website" The more detailed warning says: "The certificate authority, who provided the certificate, is not trusted." The messages are translated into english, so please excuse slight differences there. After this message, I get the message of Java, which shows that the Applet is ordinary signed (the dialog with the blue sign). So the Applet is working, only the warning message annoys.

Before I moved to another server, everything was fine and worked. No security warnings or anything else. The Applet is signed, by a certificate, which I requested from an CA. (rapidssl) The old server environment was just a common web space, offered by 3rd party hoster. Now I moved to my own server, which utilizes XEN for hosting VMs. On one of that internal vm's, our webserver is deployed. According to that, I defined firewall rules to route traffic http/https to the vms. Also the domain was ported, was purchased at old hoster, and the ip of new server is bound to domain. I use Tomcat 7 as Application Server on an debian based OS.

In old environment, I could use the specified url in CN of my wildcard cert.(e.g. *.domain.com) In new environment the basic message says: *.domain.com:port is not a trusted site. I thought actually, that SSL Certs are independent of the used port. I've read that, on some research too. I also searched here in many threads, but the supposed answers didnt work for me.

The certificate and root cert. are imported to Java's own keystore cacerts. In Tomcat 7, I use the JSSE Implementation for SSL, with properly setup keystore files.

I've tried already this, but as im not that experienced with SSL/TLS Technology, the tried solutions maybe even wont solve my problem:

  • Disabling SNI in Tomcat 7 (dont work)
  • Adding Host aliases in server.xml (dont work)

Can anyone clarify, what the actual problem is, or has experienced the same issue ?

@edit: The are no error stacktraces in any logs, which I could provide here, also no exceptions gets thrown.

user3880352
  • 61
  • 1
  • 1
  • 7
  • Is the chrome client the same as earlier or in a different box? If it is then it is missing the root cert of the ca. It could also be that u are misding the intermediate ca certs in the server's keystore. – Khanna111 Jul 26 '14 at 19:45
  • Yes its the same client. The imported root cert is a bundle of a root cert and intermediary cert, contained in a single file. – user3880352 Jul 26 '14 at 20:01
  • checked again the root bundle is correctly imported in servers keystore, contains 2 entries, root CA+Intermediary bundle + private cert – user3880352 Jul 26 '14 at 20:14
  • K. Is the intermediate ca cert is made available to the client? You can check with tcpdump. Or you could add the intermefiate as trusted on the client to reduce the scope of the issue. – Khanna111 Jul 27 '14 at 06:38
  • *"The imported root cert is a bundle of a root cert and intermediary cert"* - The server is supposed to send server's certificate and all intermediate certificates to avoid the "which directory" problem. That's what client software expects. The client software must already have (and trust) the root. What is the output of `openssl s_client -connect :`? – jww Jul 27 '14 at 08:00
  • *"In old environment, I could use the specified url in CN of my wildcard cert.(e.g. *.domain.com)..."* - Placing a DNS name in the CN is deprecated by both the IETF and CA/Browser Forums. Instead, make the CN a friendly name like *My Domain*, and place the DNS names in the SAN. Also, wildcards *may* get special handling for an applet (I don't know, maybe Bruno or EJP could comment). You might try a non-wildcarded cert. – jww Jul 27 '14 at 08:10
  • *"I thought actually, that SSL Certs are independent of the used port"* - That is correct. Future standards intend to make SSL/TLS a little more ubiquitous via Application Layer Protocol Negotiation (ALPN), but it won't depend on port numbers. – jww Jul 27 '14 at 08:14
  • Also see *[What should I do when I see a security prompt from Java?](https://www.java.com/en/download/help/appsecuritydialogs.xml)*. Most of the entries talk about Java applet warnings. And see the Signed Code FAQ at *[Java Content in the Browser — Security Manifest Changes](http://www.java.com/en/download/faq/signed_code.xml)*. From the FAQ: *"As of 7u51, (January, 2014), your Rich Internet Applications (RIAs, also known as Applets and Web Start applications) must be updated. The updates required are on the packaging and distribution; no API code changes should be required"*. – jww Jul 27 '14 at 08:16
  • okay the output of ssl debug listed some verify errors: verify error:num20:unable to get local issuer certificate, verify error:num=27:certificate not trusted, verify error:num=27:certificate not trusted, Verify return code: 21 (unable to verify the first certificate). This clarifies, what the issue here is.. the keystore was not setup correctly, I guess. However im wondering, why the ssl connection worked in browser, by just visiting the site and only the loaded applet gave me the tip, that there is something wrong with the ssl connection. I'll provide a detailed answer to this issue – user3880352 Jul 27 '14 at 13:08
  • guys, thank you very much, would give u votes, but I'm not allowed, since im new on the platform, i guess. – user3880352 Jul 27 '14 at 13:30

1 Answers1

0

It came clear, thanks to Khanna111 Gaurav Khanna and jwv, that the certificate chain wasnt setup properly. I thought, if there were any problems with the certificate chain, that the browser will notify me about it. It isn't like that. As we migrated from old hoster to new server, they provided only the certificates, but without the private key. As im not that much experinced with SSL, I thought that importing the intermediary certs and the acquired cert is enough.. It is not :)

After stumbling on intermediate-ca-certificate-in-java (link in comment), I've read this, which solved my problem: why doesn't java send the client certificate during SSL handshake? & external website:Import private key and certificate into Java Key Store (JKS)

I had certkey.key,publiccert.crt, intermediate_primary.cer and secondary_primary.cer Files.

The first step was, to convert the .key and .crt file to DER format, as mentioned in last link via OpenSSL due to keytool's inability to import a key in an existing keystore After converting to DER Format, I used the Tool ImportKey and created a new keystore with key/cert contained.

The second step was following the instructions of second link (Bruno's Answer), so it was copy&paste the certificate contents, into a single file. After importing the bundle of certificates into keystore, everything was fine.

I hope this can help anyone else, which is also not that familiar with SSL.

p.s. due to my lack of rep, i cannot mention all sites, I've used.. I'll provide them in comments

Community
  • 1
  • 1
user3880352
  • 61
  • 1
  • 1
  • 7
  • the link to intermediate-ca-certificate-in-java: http://stackoverflow.com/questions/19453523/intermediate-ca-certificate-in-java-keystore – user3880352 Jul 27 '14 at 13:29