• gd_bundle-g2-g1.crt: Go Daddy Certificate Bundles - G2 With Cross to G1, includes Root
• gdig2.crt: Go Daddy Secure Server Certificate (Intermediate Certificate) - G2
• 2b9918dccf2f1d.crt: Your certificate

Source: https://certs.godaddy.com/anonymous/repository.pki

1. 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.

2. 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.

3. 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).

A server providing a TLS/SSL connection (as in a HTTPS web-server) should send the client all certificates in the chain. That is, the end-entity certificate, all subordinate CAs and optionally (but not mandatory) the Root CA certificate.

Your so called Affected PCs are showing the symptom of a web-server that has been misconfigured and is simply sending the end-entity certificate. Your browser gets this certificate and has no way to chain it to the Root CA that's installed in your trust-anchor store.

Your Unaffected PC is showing the symptom of a Windows computer which conveniently has the subordinate CA certificates cached in its certificate store. These are usually placed there when a user browses to another website which uses the same subordinate CAs but whose administrator knows what they are doing :-) The PC is still only receiving the end-entity certificate from the server, but as it has the subordinate CAs certificates cached, it can join them together and build the chain.

Now, Windows has a facility to download any subordinate CAs from a repository, but this will only work if (a) the URL of this repository is contained within the certificate, (b) the certificate is actually installed on that repository, and (c) the repository is online and accessible.

To resolve this, you need to have a stern word with the administrator of the website and tell them to read RFC 5246. Specifically, section 7.4.2.

Please check this dev forum link. You need to upload a single file that contains the SSL certificate, Intermediate CA Certificate and then the Root CA Certificate in that order.

1.Open a Notepad or any Text Editor.

2.Paste each certificate as per below order.

-----BEGIN CERTIFICATE----- 
(SSL certificate) 
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- 
(CA Intermediate certificate) 
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- 
(Root certificate) 
-----END CERTIFICATE------

3.Save the file as ".cer" file. Now upload the newly created ".cer" in Salesforce.

You probably need the gdig2.crt listed at the GoDaddy Certificate Repository. It should have also been included in the bundle you downloaded.

Once you have that, and know the root certificate, you can verify it with:

openssl verify -verbose -CAfile <(cat gdroot-g2.crt gdig2.crt) yourcert.crt

If it is ok you should see something like <certname>:OK

Once you've made sure that all works, then you can retry your SSLLabs test.

Hope that helps. =)

So the problem was several mistakes along the way for me. First, I took the -----BEGIN CERTIFICATE----- section from the PEM generated from my keytool keystore. Second, I was trying to convert the gd_bundle-g2-g1.crt file - it already contained exactly what I needed to use.

To start from the beginning - I used Digicert's Java Keytool to generate my commands to get my keystore and CSR using keytool. From there, I got a wildcard SSL certificate through GoDaddy and downloaded my certificate which was in a ZIP file along with gdig.crt and gd_bundle-g2-g1.crt. After this, I follwed to steps to get the private key from my keystore following this StackOverflow answer. However, the foo.pem file from this command required one more command, openssl rsa -in foo.pem -out foo.rsa to get the final form accepted by the AWS panel.

Now to fill in the SSL form on AWS:

• Private Key: The contents of the foo.rsa file from the previous step.
• Public Key Certificate: The contents of the <your_cert>.crt file provided by GoDaddy
• Certificate Chain: The contents of the gd_bundle-g2-g1.crt file provided by GoDaddy

This has given me a successful SSL certificate setup for my AWS ELB, with the proper certificate path, giving me a trusted certificate.

If can help someone.Tomcat 8

You don't need the xxxx.crt.pem file. Just run the following command on your original version of the keystore file (if renew certificate) for new certificate just use the same keystore file you've just create to get the csr.

So after you receive your zip file from Goddady type the following command.

keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt

keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file 123456fgscd.crt

sudo initctl restart tomcat

Don't forget to setup Catalina to point to your keystore (server.xml file)

Bingo.