Issue
When trying to connect to a Contrast https URL using a Java "client" (this could be the Contrast Java Agent OR this could be any of the Contrast plugins that are used by a java application (such as Eclipse or IntelliJ)), an error like one of the following occurs:
No subject alternative names present
No subject alternative DNS name matching
No subject alternative names matching IP address
Conditions present when this occurs:
1. Connecting to the same Contrast https URL from a browser does not give any problems.
2. Instead of the Contrast server hostname being used in the Contrast https URL, the IP address is used instead, eg https://172.31.11.11:8443/Contrast
Cause
The "No subject alternative names" error is a result of java using a stricter hostname verification method than what most browsers use. This is best explained in this Stack Overflow discussion: https://stackoverflow.com/questions/10813959/difference-in-dealing-with-ssl-certificate-in-respect-of-browser-and-jvm
Basically, java follows the rules set forth in RFC 2818 (the HTTPS specification), Section 3.1 ; this is the relevant extract of the specification from that section:
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
Therefore, when the IP address is used instead of the hostname in the https URL, the server certificate must have a SAN (Subject Alternative Name) that is an IP address matching exactly the IP address used in the https URL.
Resolution
If you are using a self-signed certificate, then you will have to regenerate the self-signed certificate so that it includes a SAN extension containing the server's ip address(es). You can do this using either keytool or openssl. Below are examples for each:
Keytool:
$ keytool -keystore contrast_server.jks -storepass YOUR_STORE_PASSWORD -deststoretype jks -genkeypair -keyalg RSA -validity 365 -alias contrastserver -dname "CN=<SERVER_HOSTNAME_OR_IPADDRESS>, OU=<YOUR_ORGANIZATIONAL_UNIT>, O=<YOUR_COMPANY>, L=<YOUR_CITY>, ST=<YOUR_STATE>, C=<YOUR_COUNTRY>" -ext "SAN=DNS:www.mycompany.com,IP:<IP_ADDRESS_1>,IP:<IP_ADDRESS_2>"
Openssl:
$ openssl req -x509 -nodes -days 730 -newkey rsa:2048 -keyout cert.key -out cert.pem -config req.cnf -sha256
where req.cnf contains:
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = <YOUR_COUNTRY>
ST = <YOUR_STATE>
L = <YOUR_CITY>
O = <YOUR_COMPANY>
OU = <YOUR_ORGANATIONAL_UNIT>
CN = <SERVER_HOSTNAME_OR_IPADDRESS>
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.yourcompany.com
IP.1 = <SERVER_IP_ADDRESS_1>
IP.2 = <SERVER_IP_ADDRESS_2>
If you are using a CA-signed certificate, it is up to the party signing the CSR to include the desired extensions such as the SAN list. Contact the party responsible for signing of the CSR to get the desired SAN list included in the signed certificate.
Verify that your self-signed certificate or your CA-signed certificate includes a a SAN list:
Example showing a self-signed certificate with a SAN list:
$ keytool -printcert -v -file selfserver.crt
Owner: CN=test.acme.com, O="Acme, Inc.", L=SZ, ST=GD, C=CN
Issuer: CN=Acme Root CA, O="Acme, Inc.", L=SZ, ST=GD, C=CN
Serial number: e13b9708133128fc
Valid from: Mon Apr 12 16:36:31 UTC 2021 until: Tue Apr 12 16:36:31 UTC 2022
Certificate fingerprints:
SHA1: FB:C7:D1:EC:A2:30:07:FE:DB:9C:4D:7D:C7:F2:F2:3C:AB:F4:10:15
SHA256: 7A:C2:11:90:44:30:60:5D:76:CA:36:E5:AD:EE:40:4B:F7:96:1E:D4:54:E0:14:8B:D7:9F:63:6A:B9:93:BD:34
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: www.example.com
IPAddress: 172.33.124.78
]
Example showing a CA-signed certificate with a SAN list:
$ keytool -printcert -v -file signedserver.crt
Owner: CN=test.example.com, O="Acme, Inc.", L=SZ, ST=GD, C=CN
Issuer: CN=Acme Root CA, O="Acme, Inc.", L=SZ, ST=GD, C=CN
Serial number: e60943eccc6777ca
Valid from: Fri Apr 16 19:49:51 UTC 2021 until: Sat Apr 16 19:49:51 UTC 2022
Certificate fingerprints:
MD5: 00:D2:78:C2:72:21:C1:58:8E:DC:2F:7F:AB:2C:3D:DF
SHA1: E6:2D:C6:86:E0:B4:CF:77:C0:B7:3F:76:AB:12:4D:13:D1:C2:83:C0
SHA256: 2F:2E:60:EC:13:B6:89:A6:EE:D8:73:DD:D0:01:2F:33:2A:C6:FF:9F:5C:79:8B:15:C3:4A:9C:CE:AC:11:02:4D
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: www.example.com
IPAddress: 172.31.111.111
]