A DESCRIPTION OF THE PROBLEM :
A TLS server with EC key pair offers both ECDH and ECDSA ciphers, regardless if the certificate has KeyUsage equal to keyAgreement (required for ECDH), digitalSignature (required for ECDSA), both, or none.

Internally the only thing about certificates that is checked during cipher selection is if the key type matches. Here's the interesting portion of stack trace:
chooseServerAlias:260, SunX509KeyManagerImpl (sun.security.ssl)
createServerPossession:288, X509Authentication$X509PossessionGenerator (sun.security.ssl)
createPossession:214, X509Authentication$X509PossessionGenerator (sun.security.ssl)
createPossession:90, X509Authentication (sun.security.ssl)
createPossessions:51, SSLKeyExchange (sun.security.ssl)
chooseCipherSuite:443, ServerHello$T12ServerHelloProducer (sun.security.ssl)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Verify that the server offers ciphers that should not be offered given the KeyUsage extension. For example:
- Generate ECDSA self-signed certificate
- Start SSLServerSocket using that certificate
- check available ciphers with nmap

Generate self-signed ECDSA certificate:
keytool -genkeypair -alias ec -keyalg EC -keysize 256 -sigalg SHA256withECDSA -validity 365 -dname "CN=localhost,OU=Unknown,O=Unknown,L=Unknown,S=Unknown,C=Unknown" -storetype JKS -keystore ectest.jks -storepass 123456 -ext KeyUsage:c=digitalSignature,keyCertSign

Check available ciphers with nmap (assuming localhost:443):
nmap --script ssl-enum-ciphers -p 443 localhost

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
nmap should not list ECDH ciphers
ACTUAL -
nmap lists both ECDH and ECDSA ciphers

CUSTOMER SUBMITTED WORKAROUND :
If only ECDSA is required, a possible workaround involves disabling ECDH support.

FREQUENCY : always