DHE ciphers not exposed by BouncyCastle provider - ssl

Question

I have Java TLS server and have switched from the original SunJSSE provider to BCJSSE (BouncyCastle JSSE FIPS, v1.0.10).
Now if someone tries to query my server with nmap -sT -Pn --script ssl-cert,ssl-enum-ciphers -p , ciphers having enabled DHE key exchange algorithm were shown and the handshake was successful:
ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
Having the BCJSSE provider, which claims to support the above DHE ciphers, nmap returns:
ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
When running:
openssl s_client -tls1_2 -cipher DHE-RSA-AES128-CCM -connect <host> <port>
actually the handshake is successful with the DHE ciphers. However, running curl, compiled with the very same version of openssl:
curl -vvv -k https://<host>:<port>--tlsv1.2 --ciphers DHE-RSA-AES128-CCM -u <user>:<pass> -c /tmp/cookie
the result is:
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
The old crypto provider used to handshake successfully for each of the supported ciphers (not the last one which is available only in BC).
The BCJSSE documentation says:
Cipher suite name: TLS_DHE_RSA_WITH_AES_128_CCM
FIPS mode: N
which I interpret as supported.
So, does anyone knows why there is a difference between the nmap outputs and how it is possible to have a successful handshake with s_client but curl refuses to establish such a secure connection. And is there something particular to be fixed here and how, or this might be considered as expected behavior?