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.

I will answer your question, but I'd like to kindly point you in the direction that will help you get better assistance in the future before I do.

First, there is a reason your question hasn't got much attention. It is asked in a way which is not going to get answers from the gate. 1) This is more of a question for serverfault, since it has to do more with web server administration than programming. 2) you didn't mention apache in the title. 3) You mention a specific company, Godaddy, something like "Installing an SSL certificate in Apache 2.x" would probably be better, and then mention the specifics about how your CA issues a certificate. This is a really common question, and there are probably existing threads which it is clear you didn't read before asking a question. This goes beyond your single problem, but will help you better answer every single question you have in the future a bit better. See http://www.catb.org/esr/faqs/smart-questions.html

This is probably an excellent opportunity to read up on some documentation about how SSL certificates work, and how they are configured in Apache as well.

Because I've already filled one line with gd_bundle.crt so my guess it is another file, but which one out of that repository link?

None of them, that link only contains the Certificate Chain and Root Certificates.

Rather than try to describe what a Certificate Chain file is, IBM has done a much better job than I. This is step #1 in understanding how to solve your problem:

How certificate chains work

When you receive the certificate for another entity, you might need to use a certificate chain to obtain the root CA certificate. The certificate chain, also known as the certification path, is a list of certificates used to authenticate an entity. The chain, or path, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. The root CA certificate is always signed by the CA itself. The signatures of all certificates in the chain must be verified until the root CA certificate is reached.

This means basically, that the Certificate Chain file is what you will need in order for your certificate to be properly verified. A .crt file indicates it contains public, private, and root certificate files in one file, or some combination thereof.

Step #2

A .pem file usually means just one public certificate, this is the file you will use for SSLCertificateFile. Naming this file with .crt is only canonically correct if theres more than one cert in there, which most likely there is not if you are getting a cert from your CA. You mentioned you received some files from Godaddy, one of them is going to be this file.

Step #3

SSLCertificateKeyFile will be a private key file that was provided at some point after / during your certificate was issued. I can't say exactly what Godaddy's process, I can only describe the fundamentals of the process, and each CA is different in how they issue certificates. Don't forget to set the proper permissions on this certificate (in fact I think Apache will fail to start if this file is not set to 600 permissions).

This should give you enough information to go on to get up and running. Anything else that involves navigating Godaddy's SSL issuance process is a question more for Godaddy support than StackOverflow / ServerFault.

Good luck.

The workaround is to contact GoDaddy and have them reissue your organization's certificate. During the certificate setup process, you must select a SHA-1 codesign certificate instead of SHA-2. The option to select SHA-1 will only be available if you certificate validity does not extend to 2016 (see below), so make sure they understand your end goal is to recreate your SHA-2 certificate as SHA-1, so they know to sell you a cert with the correct validity period.

I traded my SHA-2 cert for a SHA-1 today, and GoDaddy's Java Code Signing instructions worked perfectly.

GoDaddy informed me Keytool may have trouble importing a certificate response chain generated from their SHA-2 (2048 length) codesign certificate. I withhold judgment of Keytool since it imports SHA-2 certs fine when the GoDaddy's root SHA1 cert is lopped from the pem file per @mogsie's answer.

GoDaddy goes with SHA-2 automatically when it grants codesign certificates that will extend into 2017 because Microsoft will not accept less than SHA-2 beginning January 1, 2016, so if you're in the market for a SHA-1 certificate, it will have short-term validity.

The issue might go away with a Java Keytool update (I was working with 1.6), or if GoDaddy's Sha256withRSA self-signed certificate becomes widely trusted.