Public certificate authorities don't issue certificates directly from their root, but instead through an intermediate certificate (for security and administrative reasons).
Without having the intermediates, it's impossible to make the link between your cert and DigiCert This means that in order to verify your server certificate, it's not enough to just trust the DigiCert root – clients must also obtain all intermediate issuers in the chain.
Web browsers can do so in various ways: they can fetch certificates from the AIA URL stored in your server cert, and they can cache intermediate issuers seen previously, so various incomplete configurations appear to work "fine" when visited through a browser.
But barebones TLS clients aren't as flexible (I mean, they cannot make any extra HTTP requests, nor expect to have a writable cache) and so the intermediate certificates must be supplied by the TLS server itself.
If the webserver takes a single PEM (.crt) file, then that file needs to have the correct intermediate certificates appended to it.
If DigiCert sent you a .zip with the certificate via email, one of the included files is the intermediate cert, and you can concatenate both files using
cat or a text editor. (The server cert always goes first, its direct issuer next, and so on. Root would go at the end, but it's redundant here so don't include it.)
If the webserver wants a PKCS#12 file, and you made that file with
openssl export, then re-export it and specify the intermediates using OpenSSL's
-CAfile option. (Alternatively, give it the combined .crt as
If the webserver uses a Java keystore,
keytool -importcert might work? (Recent versions of Java support and indeed prefer directly using PKCS#12 files as keystores, so this might be redundant. Honestly I've no clue.)
Verify your configuration using SSL-Tools or Qualys SSL Labs. Just opening the site with a web browser is not a good test, due to what I already mentioned.