I have been tasked with using OpenSSL to create certificates for a webservices project and then importing the certs into glassfish 3.1. I do NOT have access to Apache. (The application that is being created works with username/password verification but we want to add in certificates)
I have googled and read many tutorials, but have yet to get certs working. Does anyone know of the quintessential tutorial to point me to?
I have created the CA, CSR and CRTs using OpenSSL and have tried many ways to get them imported into Glassfish's keystore, but the closest to success I have gotten is the following log message
[#|2012-09-21T16:14:05.859-0500|WARNING|glassfish3.1.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=17;_ThreadName=Thread-2;|GRIZZLY0007: SSL support could not be configured!
java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled.
Related
Hostgator provides free Let's Encrypt SSL cert so I let my Comodo cert expire. Netbeans won't connect now and gives java.security.cert.certificateexpiredexception.
I'm in the process of renewing the comodo cert but wonder if there is a way to fix this. The plugin SSL Cert Exception in Netbeans did not fix this issue for me.
Netbeans does not want to connect to remote server because the comodo certificate expired. I get this error in the popup:
java.security.cert.certificateexpiredexception
It is not recognizing the Let's Encrypt certificate which is still valid that is also on the server.
This SSL issue did not go away when the new comodo cert was installed. But I was able to use FTP in Netbeans without TLS.
SSL issues appear to have been caching related, Hostgator have since cleared any applicable cache and issues with connecting via FTP on TLS have stopped.
I probably did not need to buy the new comodo cert to fix this issue. Sorry I don't have info on exactly which cache was cleared on the server, but maybe this is enough info to get someone who runs into this issue onto the right path.
I have bought a domain and certificate from Azure. The certificate is given by Go Daddy as azure partner and it is signed with the intermediate certificate from Go daddy hence it always needs chaining of certificates till Root CA.
Our website is used as a REST interface for our customers and hence clients use Java SDK or plain scripts. In our case precisely with zulu jdk image(11u5-zulu-alpine) from microsoft and even I tried with ubuntu 16.04 LTS and get the same error.
if we try to even curl to our site with proper certificates we get error as below and its because of the intermediate CA is missing!
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
With java SDK we get as javax.net.ssl.SSLHandshakeException
I have 3 questions.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
And lastly I have a fair idea of how certificates work w.r.t client and server but with the intermediate CA in picture I am unable to understand exactly where the intermediate CA should be put in. I read few posts on the SO but its still unclear. Please bear with me and if some one can explain me the approach how it works in general and what could be the good practice.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
You should definitely configure the server to send all required intermediate certs; this is required by the TLS standards. (Although if you don't, clients have the option to try to obtain them by other means, like a cache or repository or AIA, and sometimes they do.) Whether the server sends the root is optional; the standards actually state this in reverse, by saying the server MAY omit the root, where the all-caps 'MAY' invokes the meaning defined in RFC 2119. E.g. for TLS1.2 in RFC5246 7.4.2:
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
How you do this depends on what web-server software you are using, which you didn't identify. Although from the fact you specify a Java version, I can speculate it might be Tomcat, or something based on Tomcat like Jboss/Wildfly. Even then, Tomcat's SSL/TLS configuration varies substantially depending on the version and which type of connector 'stack' you use (the pure-Java JSSE, or Tomcat Native, aka APR Apache Portable Runtime, which is actually OpenSSL). However, a 'pfx' (PKCS12) file can definitely contain both a privatekey and the matching (EE) certificate PLUS the chain cert(s) it needs, and is a convenient way to deal with the whole kaboodle at once.
For a cert obtained directly from GoDaddy, they provide instructions linked from https://www.godaddy.com/help/install-ssl-certificates-16623 for many common servers. I don't know if for Azure they use any different chaining that would alter these instructions.
If your server is publicly accessible, at port 443, https://www.ssllabs.com/ssltest will check if it is correctly handling the chain certs, as well as many other things. There are other tools as well but I am not familiar with them; for non-public servers I usually just look manually.
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Clients should not install intermediate cert(s) because as above the server should send them. The GoDaddy roots have been accepted in most official truststores for several years now, so most clients using default settings should not need to add them. However, some might; in particular Ubuntu 16.04 might be old enough that it doesn't have GoDaddy preinstalled. And any client(s) that wishes to use a customized truststore, and/or a pin, must ensure that it is set to include/allow your cert's trust chain.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
GoDaddy has supplied its roots to (AFAIK all) the major truststore programs, as above. IINM Ubuntu uses the Mozilla/NSS list, which definitely includes GoDaddy today, but as above I can't be sure about 16.04. I don't know for alpine. CAs do not request truststore programs to include intermediates (although a program or user may be able to add selected intermediate(s) as trusted, depending on the software used).
First to explain our application, its as follows...
1)We have one UBUNTU server where we are running Apache Tomcat and also RESTCOMM.
2) We have two application war files. One is the main application and another is a customized OLYMPUS Application to facilitate WebRTC calls. Now our Main application has a menu option which when clicked will load customized OLYMPUS Application into the browser and facilitates the WEBRTC for users.
3) We have tested this properly by using Self Signed Certficate and all is working well. But now we want to use CA apporved SSL Cert.
4) for this we have bout SSL CERT from GODADDY and for this the CSR was generated for Apache and then by using that CSR we downloaded the SSL CERT for Apache and configured by following the same process of how we configured Self Signed Cert.
5) Our main application is working well with the newly installed CA SSL Certificate. But when we try to load the customized OLYMPUS application we are getting the following error ...Web socket connection to ‘wss://>:/’ failed: WebSocket opening handshake was canelled.
We are able to get all working with self signed cert, but we are stuck with this problem when we use CA Approved SSL Cert from GO DADDY.
Request your suggestions pls.
Thanks in advance
Ias M
You need to configure Restcomm to use SSL Cert as well since the Websokets secure connection goes directly to Restcomm. Which method are you using for runnning Restcomm, using the zip file or the docker image ? Also which version of Restcomm are you running ?
I am having the same issue with client certificates that many people have reported, but none of the solutions I've seen have worked for me. I have a client I wrote in VB.Net (using VS 2010 and .Net framework 4.0) that needs to connect to a web service running on Apache Tomcat/5.0.27. It works fine with SSL when client certificates are not required, but as soon as client certificates are required, it fails with “THE REQUEST WAS ABORTED: COULD NOT CREATE SSL/TLS SECURE CHANNEL”
Testing it with Internet Explorer (8, 9 and 10, on XP and Win7x32), when SSL is enabled (configured on Tomcat by setting sslProtocol="TLS" secure="true" scheme="https" in the system.xml file), but client certificates are disabled (clientAuth="false"), IE is happy after the CA certificate and the server certificate are installed on the client PC. (IE will complain without the certificates, but you can tell it to ignore the warning. When the certificates are installed, it connects without any warnings.) When client certificates are required (clientAuth="true"), IE will not connect. After I import the client certificate file, it still does not connect. IE shows that the client file is installed, and it shows the certificate is ok and it trusts the CA, but it shows it in what seems to be the wrong store: Intermediate Certificate Authorities, and client authentication is not ticked under Purpose. The MMC certificates snap-in shows the client certificate is in the Personal - Current User store.
The certificate was issued to us by the owners of the web service, so in theory it has to work. The properties look ok, and the purpose shows "All application policies".
I need to get this to work with my .Net client. I use a Web Reference to create the connection to the web service. I set PreaAuthenticate=True, and attach the certificate file to the web reference, and can see it attached in the IDE. Using Network Monitor, I can see that the server sends certificates to the client (in two large packets), but the client doesn't seem to send any back to the server.
I have tried various recommendations, e.g. setting ServicePointManager.Expect100Continue = true and
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3, but this makes no difference.
I have disabled firewalls and proxy servers, so nothing should be blocking the traffic.
I'd appreciate any help.
Ok, it turns out there is a problem with the certificate they supplied, or it is somehow incompatible with the client. I found instructions on using OpenSsl to create a certificate, and it works with their server. They used java's keytool to make the certificate, so either it creates an incompatible certificate, or they didn't use the right procedure, and the procedure I used with OpenSsl is the correct one.
The steps in OpenSsl are to create a private key file (client.key), create a certificate request (client.req), sign the key (client.pem) then export it (client.pfx).
I'm setting up my development environment using the binary files that I have downloaded from WSO2's website.
I'm getting an issue related to the SSL certificate which prevents me to call some URI's from my Ruby script. How can I can fix this kind of problem?
Have you tried installing the SSL Certificate into the client-truststore in repository/resources/security?