Products | Versions |
---|---|
TIBCO BusinessConnect | - |
Not Applicable | - |
Resolution:
Notation:
internal BC: BC_INT
DMZ BC: BC_DMZ
partner's business app: PARTNER_APP
server certificate chain in keybag 1: PKCS12_BAG1
server certificate chain in keybag 2: PKCS12_BAG2
Scenario:
In case, the trading partner enforces ssl client authentication AND it requires server
certificates to be presented by
the BC deployment, the BC environment will require two different server certificates due to the
following:
inbound: PARTNER_APP ? BC_DMZ: BC_DMZ presents a leaf certificate from PKCS12_BAG1 which has a
Common Name
reflecting the BC_DMZ public hostname (e.g. bcdmz.company.com). PARTNER_APP verifies the chain
and verifies that
the X500 common name belongs to BC_DMZ from the X.509 leaf certificate. The rest of the handshake
is not significant;
outbound: BC_INT ? PARTNER_APP: BC_INT verifies PARTNER_APP and also, will be requested to send
its chain to
PARTNER_APP due to the client authentication enforced by PARTNER_APP. In case, PKCS12_BAG2 ==
PKCS12_BAG1,
the leaf-to-be-presented by BC_INT will be the same as presented by BC_DMZ. The source IP address
from BC_INT (or the outbound
proxy) will likely not resolve to the X.500 common name of the X.509 leaf certificate used by
BC_DMZ. This results in that PARTNER_APP
rejects the outbound session due to that the server certificate requirement cannot be enforced.
The visible address of BC_DMZ is a static host/domain name resolved from a static IP address
while BC_INT's visible address
will likely be a dynamic value or if even if there is a static NAT map, its host/domain name
should be different from BC_DMZ's
In this case, configuring BC_INT with PKCS12_BAG2 and BC_DMZ with PKCS12_BAG1 while (PKCS12_BAG1
== PKCS12_BAG2)
introduces the problem. If BC_INT is using PKCS12_BAG2 where the leaf certificate has the common
name of the visible host/domain
name for the outbound session, the problem can be resolved. Although the user might need to be
aware of that this requires
2 different certificates instead of one, which in turn, would require the purchase of 2 server
certificates instead of one, assuming a public CA.