Back end communication on port 9443 uses Self-Signed certificate = We need ability to change cert to an Authorized certificate

Jens, I had a ticket, which is how I got that command in the first place: 01677701
I’ve re-opened the ticket and mentioned out conversation.

Mark,

I guess the XML tags were stripped away from your snippet. Please contact Support so that they can assist you further.

Jens,

I followed this note, which was given to me by TIBCO support:
https://support.tibco.com/s/article/How-to-upgrade-Node-Manager-s-certificate-hashing-algorithm-from-SHA1-to-SHA2
Which is the same command you just sent me, so yes, that is implemented. I included the snippet from the confinguration.xml which it shows that parameter being set. The configuration was that imported back to the database:

SHA256withRSA

Have you set the signature algorithm, or just the cipher suites? If you did change the signing algorithm (like shown below), did you import the configuration and restart the Spotfire Server afterwards? Note that to also have the CA certificates to be signed with the new algorithm you also need to run the "reset-trust" command.

set-config-prop -n "security.ca.cert-signature-algorithm" -v "SHA256withRSA"

If the problem persists please contact TIBCO Support. Also note that the default value is SHA256withRSA in Spotfire Server 10.1 and onwards.

Jens,

I’ve built a new environment with all SHA256 algorthims, and a 256 root certificate and Spotfire still only returns a SHA1 self-signed cert. It appears it is not using the current algorithms and this is a security problem. SHA1 is weak and it mandated that it be replaced with SHA256. It is a security problem.

From the currently configuration:

SHA256withRSA

Output on how servers are communicating on port 9443.

[esfrs@spxtsrv1 certs]$ openssl s_client -connect spxdsrv1.gpe.fedex.com:9443 | openssl x509 -text
depth=2 O = Spotfire, CN = TIBCO Spotfire Root CA
verify error:num=19:self signed certificate in certificate chain
140169160165264:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:s3_pkt.c:1493:SSL alert number 42
140169160165264:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e8:96:cf:6e:18:c2:65:5f:0e:27:e5:5f:44:9b:34:43:bd:aa:23:a0
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Spotfire, CN=TIBCO Spotfire Signing CA
Validity
Not Before: Feb 18 14:05:02 2019 GMT
Not After : Feb 18 14:05:02 2020 GMT
Subject: O=Spotfire, CN=2919739f-8d4d-4022-843c-42fde43879c9
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:98:5f:ea:0f:8b:c4:ec:0b:9b:2e:87:20:4b:ea:
c1:d6:8c:9e:50:da:e9:33:ee:24:62:f0:e1:59:90:
26:87:eb:37:3b:06:3d:75:ea:4a:e8:4b:fd:48:1c:
3c:f1:d2:56:24:0b:16:0d:c3:eb:ae:2d:0f:0d:54:
56:cb:9b:d7:89:b2:c1:32:4c:ae:80:21:df:0d:45:
f4:21:13:94:8a:34:ee:7d:34:3d:87:79:e5:d2:d5:
fd:59:ba:ec:c6:d2:02:76:39:e1:30:0f:f6:bc:a4:
87:6d:a6:d8:7a:30:e6:10:40:c8:4c:06:e1:ca:4e:
9e:74:e7:44:e5:3c:06:2d:15:00:d2:3c:42:9d:cf:
f6:8c:20:e2:3e:4f:d4:d1:6b:90:f9:3e:f2:a8:c9:
44:a9:fb:77:cb:d0:0a:42:6a:d8:d5:08:de:80:c7:
4b:96:14:c6:37:40:5a:e3:80:90:2c:1c:ba:dc:51:
6a:2a:20:ab:a8:6c:21:a7:59:a4:63:ca:2b:ab:25:
dd:9c:39:72:47:07:12:0d:46:f5:34:df:92:3d:10:
e0:2e:4b:ba:9e:f0:b9:38:17:ce:df:3c:35:32:6b:
9f:96:7b:77:99:64:49:4c:39:77:13:af:a9:47:df:
08:af:4c:ea:4d:be:f4:35:5c:2a:97:b4:11:df:02:
29:3f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:ED:E7:CA:C1:0D:12:B7:51:F5:D0:F9:41:80:5B:5A:89:25:3F:4F:0E
DirName:/O=Spotfire/CN=TIBCO Spotfire Root CA
serial:91:FF:AB:50:CB:45:84:A9:B4:CD:E3:52:8C:D7:2A:81:E1:D2:18:88

X509v3 Subject Key Identifier:
A4:FD:5E:04:DF:BC:4F:A1:0C:F3:2C:AD:E5:AC:CD:E2:1F:26:3A:21
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:spxdsrv1.gpe.fedex.com, IP Address:199.82.153.177, DNS:199.82.153.177
Signature Algorithm: sha1WithRSAEncryption
0b:9b:bc:75:de:82:b4:0c:37:34:9b:b3:a5:67:19:e1:75:44:
2e:18:cc:c0:1e:5c:7b:30:4c:30:02:2c:e3:09:73:ea:f6:96:
25:31:cf:c8:29:d1:26:4a:30:ae:ef:b8:dd:59:49:55:39:7b:
b7:4b:b5:d5:53:6c:2b:45:6b:5e:e8:0d:f3:00:19:e9:8d:51:
3a:0f:83:43:30:ff:ca:f6:72:96:e0:c0:9e:b7:72:f7:6e:05:
35:f0:b9:61:b7:a6:79:ed:c8:d0:28:8f:21:a2:97:b2:2f:81:
e4:9c:3f:3b:fc:d0:37:cd:b1:05:e2:6b:1c:4e:54:94:c1:f4:
f8:71:2e:fb:57:81:e1:f0:17:ae:32:59:f1:cb:45:a1:67:e5:
d2:d8:5e:4b:35:4b:77:ff:5b:1f:55:3c:d3:ad:3f:4b:0f:77:
54:b9:47:5a:46:ae:e8:f5:ec:77:a2:73:52:b4:3c:c3:96:27:
4a:b8:a8:17:f6:a7:e6:ee:86:0b:db:2c:bd:e4:bd:b4:95:af:
8f:fd:9e:74:60:93:0e:01:53:8c:9d:f5:6f:8a:00:1d:0a:f5:
c3:d4:d9:d1:72:44:3f:da:42:d4:a9:e9:fb:75:72:63:64:1b:
a5:1d:b7:ad:3f:80:b2:96:79:e4:51:89:08:e8:33:9c:55:91:
5c:e8:b1:8d

Reply to this message and your response will be added to the idea.

[Logo for TIBCO Ideas Portal]

Jens Borgland responded to idea Back end communication on port 9443 uses Self-Signed certificate = We need ability to change cert to an Authorized certificate
Jens Borgland 2:43pm

I can see that it may violate some policy but please explain the actual negative effects that it has (from a security standpoint)?
Mark Pomerantz 2:09pm

The issue is the software is still listening on a network. The authentication piece is a completely separate issue. The problem, as network security sees it, is an untrusted certificate authority, no matter what kind of communication is behind it. That violates our policies.
Jens Borgland 2:01pm

The client and the server would not have to be issued by the same CA no, but they are currently - and that should not be a security problem for the reasons I outlined.

Security scanners are indeed useful tools but they do also provide a lot of false positives.
Mark Pomerantz 1:54pm

Using certificates for authentication is a separate issue from the certificate used to setup the SSL/TLS network connection… using an internal CA to generate authentication certs shouldn’t require using the same CA for the cert used on the network port.
Jens Borgland Feb 13, 2019

Neither the server nor the client certificates used by the various components of the system are self-signed - they are all signed by the Certificate Authority that is part of the Spotfire Server. The Spotfire Server's root (CA) certificates are of course self-signed - but so are all root certificates. Each Spotfire Server installation generates it's own unique root certificate (which if needed can also be revoked using the reset-trust command).

The backend ports are only intended for communication between the components of the system (not for generic clients like web browsers to connect to) and requires all connecting clients to provide client certificates (issued by the internal CA).

Remote nodes are only issued certificates after an administrator has approved this (which should only be done after verifying the CSR signature to ensure that it's the right node that gets trusted). All nodes will then verify the certificates of remote parties (both when acting as clients and servers), including the signature and revocation (remote nodes does this using OCSP towards the Spotfire Server) - ensuring that a node that gets untrusted immediately (within 60 seconds depending on caching) can no longer communicate with the system.
Mark Pomerantz Feb 8, 2019

This needs to happen. The self-signed certs violate many security policies.
View idea

You are receiving this email because you subscribed for updates on this idea. You may unsubscribe from updates on this specific idea or from all ideas in TIBCO Ideas Portal.

I can see that it may violate some policy but please explain the actual negative effects that it has (from a security standpoint)?

The issue is the software is still listening on a network. The authentication piece is a completely separate issue. The problem, as network security sees it, is an untrusted certificate authority, no matter what kind of communication is behind it. That violates our policies.

The client and the server would not have to be issued by the same CA no, but they are currently - and that should not be a security problem for the reasons I outlined.

Security scanners are indeed useful tools but they do also provide a lot of false positives.

Using certificates for authentication is a separate issue from the certificate used to setup the SSL/TLS network connection… using an internal CA to generate authentication certs shouldn’t require using the same CA for the cert used on the network port.

Neither the server nor the client certificates used by the various components of the system are self-signed - they are all signed by the Certificate Authority that is part of the Spotfire Server. The Spotfire Server's root (CA) certificates are of course self-signed - but so are all root certificates. Each Spotfire Server installation generates it's own unique root certificate (which if needed can also be revoked using the reset-trust command).

The backend ports are only intended for communication between the components of the system (not for generic clients like web browsers to connect to) and requires all connecting clients to provide client certificates (issued by the internal CA).

Remote nodes are only issued certificates after an administrator has approved this (which should only be done after verifying the CSR signature to ensure that it's the right node that gets trusted). All nodes will then verify the certificates of remote parties (both when acting as clients and servers), including the signature and revocation (remote nodes does this using OCSP towards the Spotfire Server) - ensuring that a node that gets untrusted immediately (within 60 seconds depending on caching) can no longer communicate with the system.

This needs to happen.  The self-signed certs violate many security policies.