Server

Once a user has been created in the portal as described above, you may set up the logon process to use public/private key. As part of the creation of a user, an FTP start directory is created. This will be relative to the root of the FTP directory, with the account directory intervening. For example, the root directory of a “bridgegate” user will default to “/bridgegate”. If this user is assigned to the “samples” account, on the system, the user home directory will be <FTP_ROOT>/accounts/samples/bridgegate. The home directory or change be changed by updating the Start Path on the User screen in the portal.  If you update the start path to  test123 the user home directory will be <FTP_ROOT>/accounts/samples/test123

To allow this user to logon using a public/private key, the public key (OpenSSH Format), you must create a directory under this user’s root / start path FTP directory called “.ssh”. In this directory, create a file called “authorized_keys”. This file contains all the public keys authorized for this user to connect to the BridgeGate SSH (SFT) server. Each public key must be in OpenSSH format, and there must be one per line. You must press the enter key at the end of each line.

To connect to this server using a BridgeGate workflow, configure the SendData workflow item to use the FTP adapter and seleect the “SSH” option from the options button. This will enable two text boxes for entering the private key file and the password. Enter the appropriate private key information and leave the password field blank.

Some versions of Windows will automatically add folders to a Quick Access section in File Explorer.  Any folders that exist in Quick Access, that exist under the BridgeGate folder, will cause the Upgrade to fail because it will not be able to rename the BridgeGate folder. If your upgrade fails, go to File Explorer and under the Quick Access section remove any folders that are child folders of the BridgeGate folder.

When starting the BridgeGate server on a new installation or upgrade of MySQL and you get the following type of exception you must either add the time zone to the my.cnf or add the time zone to the JDBC URL

Caused by: com.mysql.cj.exceptions.InvalidConnectionAttributeException: The server time zone value ‘EDT’ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) Below is the example of adding it to the bridgegate.xml under the /bridgegate/conf folder

Add serverTimezone=EST to the JDBC URL

<DATABASE_CONNECTION_POOL ACQUIRE_INCREMENT="2" AUTO_COMMIT_ON_CLOSE="false" 
CHECKOUTTIME="600" DRIVER="com.mysql.cj.jdbc.Driver" IDLETIME="600" IDLE_TEST_PERIOD="300" 
JDBCURL="jdbc:mysql://localhost/bridgegate?useSSL=false&amp;autoReconnect=true&amp;useUnicode=true
&amp;characterEncoding=UTF-8&amp;zeroDateTimeBehavior=CONVERT_TO_NULL
&amp;serverTimezone=EST&amp;allowPublicKeyRetrieval=true" 
MAXCONN="100" MAX_STATEMENTS="0" MINCONN="10" PASSWORD="..." USERNAME="bridgegate"/>

If you encounter a (Too many open files) Exception in the /bridgegate/logs/server.log log file on a Linux system your system administrator will need to increase the number of OS File Descriptors the bridgegate process is allowed to use.

1.  To increase edit /etc/sysctl.conf add the below line, save and exit

   fs.file-max = 100000

2. We also need to increase hard and soft limits Edit /etc/security/limits.conf add the below lines before the #End, save and exit

   * soft nofile 65535
   * hard nofile 65535

3. Edit the bridgegate service, vi/etc/systemd/system/bridgegate.service  and add the below  line at the of the [Service] section, save and exit

   LimitNOFILE=65535

4. Reload systemctl to apply new setting

   sudo systemctl daemon-reload

5. Restart the bridgegate service

   sudo systemctl restart bridgegate

6. Check the file limits of the bridgegate process. First find the process id for the bridgegate process

   ps -ef | grep java
   The output will look like the following. The process id is the first number after the bgate
   bgate    27919 27854 94 10:03 ?        00:18:59 /usr/java/jdk1.8.0_191-amd64/bin/java 
   -Djava.util.logging.config.file=/bridgegate/server/conf/logging.properties 
   -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 
   -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
   -XX:+UseStringDeduplication -DBRIDGEGATE_ROOT=/bridgegate -DBRIDGEGATE_SERVER=true -Xms1g -Xmx20g -XX:+UseG1GC -XX:NewRatio=1 
   -XX:ErrorFile=/bridgegate/logs/java_error%p.log -Djava.net.preferIPv4Stack=true 
   -Djava.security.egd=/dev/random -Dlog4j.configuration=file:/bridgegate/conf/log4j.xml 
   -Djava.util.logging.config.file=/bridgegate/server/conf/logging.properties -Djava.security.properties=/bridgegate/java/jre/lib/security/java.security -Dignore.endorsed.dirs= 
   -classpath /bridgegate/server/bin/bootstrap.jar:/bridgegate/server/bin/tomcat-juli.jar -Dcatalina.base=/bridgegate/server 
   -Dcatalina.home=/bridgegate/server -Djava.io.tmpdir=/bridgegate/server/temp org.apache.catalina.startup.Bootstrap start
   
   

   Next view the limits for that process id

   cat /proc/27919/limits
   

   Limit                     Soft Limit           Hard Limit           Units     
   Max cpu time              unlimited            unlimited            seconds   
   Max file size             unlimited            unlimited            bytes     
   Max data size             unlimited            unlimited            bytes     
   Max stack size            8388608              unlimited            bytes     
   Max core file size        0                    unlimited            bytes     
   Max resident set          unlimited            unlimited            bytes     
   Max processes             126055               126055               processes 
   Max open files            65535                65535                files     
   Max locked memory         65536                65536                bytes     
   Max address space         unlimited            unlimited            bytes     
   Max file locks            unlimited            unlimited            locks     
   Max pending signals       126055               126055               signals   
   Max msgqueue size         819200               819200               bytes     
   Max nice priority         0                    0                    
   Max realtime priority     0                    0                    
   Max realtime timeout      unlimited            unlimited            us       
   

BridgeGate Web Service enabled as a service supports User/Password in the SOAP Header.

Authentication : This specifies whether Authentication should be performed and if so what type. NONE : No authentication will be performed by this BridgeGate Web Service.

BASIC : Choosing BASIC will reveal inputs for user name and password. These values will be stored in the workflow for comparison against values provided in the request as follows: (Note: do not confuse BASIC with “Authorization: Basic” BASIC in this scope is referring to the username / password being provided in the workflow) The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.

BridgeGate will look for 'Username' and 'Password' in the SOAP header. Example of Soap Header
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://mytest.bridgegateintl.com/websvcs/usertopersonservice/xsd">
  <soapenv:Header>
    <Username>admin</Username>
    <Password>YWRtaW4=</Password>
  </soapenv:Header>
  <soapenv:Body>
    <xsd:Root>
    <xsd:User>
     <xsd:Age>23</xsd:Age>
    </xsd:User>
   </xsd:Root>
 </soapenv:Body>
</soapenv:Envelope>

The Username field is assumed to be plain text.

The Password field is assumed to be base64 encoded.

BRIDGEGATE : The BridgeGate Web Service will authenticate the values provided in the request against the BridgeGate Users as follows: The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.

BridgeGate will look for ‘Username’ and ‘Password’ in the SOAP header. (See above example)

The Username field is assumed to be plain text.

The Password field is assumed to be base64 encoded.

The username and password will be authenticated against the BridgeGate Users and the Users must have BridgeGate Web Service portal permissions.

Failed Authentication : Results in an AXIS Fault being returned with faultcode of “401” and faultstring of “Authentication failed : Username or Password is incorrect or User does not have security rights”. Either correct the Username and/or Password and resend your request or if doing BRIDGEGATE Authentication confirm that the user has the “BridgeGate Web Service” protocol permission.

If your server.log file has the following ERROR and the server will not start the MySQL server is configured for binary logging.

ERROR [com.oidev.bridgegate.db.SchemaMigratorUtil] java.sql.SQLException: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

To resolve this add the following to the my.cnf file under the [mysqld] section

log_bin_trust_function_creators=1

Use the following linux commands to move the mysql or mariadb database location from the default installation location to a new drive

Step 1 – Mount new drive (SSD preferred)

If you Instance doesn’t already have a SSD attached to the instance use the AWS console to add a new SSD drive to the instance.

Go to Volumes and Create a General Purpose SSD  then attach it to your instance

Run the following command to view the attached drives and locate the device name.  It should be the device that has no mount.  ie  no / or /data In this example xvdc is the new drive

lsblk

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

xvda    202:0    0   10G  0 disk └─xvda1 202:1    0   10G  0 part / xvdf    202:80   0  150G  0 disk /data xvdc    202:32   0  100G  0 disk

Format the drive (Only if it is a new drive)
sudo mkfs.ext4 -Tnews /dev/xvdc

Create the new root folder for the drive

sudo mkdir /edata

Get the UUID For the drive.  Copy the UUID and add the new mount to /etc/fstab

blkid /dev/xvdf

/dev/xvdf: UUID=”b5c25450-84da-40a9-907b-b34071a9407e” TYPE=”ext4″

# sudo vi /etc/fstab Add the line below to the end of the fstab.  Using the UUID for the new drive.

UUID=b5c25450-84da-40a9-907b-b34071a9407e /edata ext4 defaults,nofail 0 0

Test mounting the drive.  You should see the /edata as the mount point for your drive

sudo mount -a
lsblk

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

xvda    202:0    0   10G  0 disk └─xvda1 202:1    0   10G  0 part / xvdf    202:80   0  150G  0 disk /data xvdc    202:32   0  100G  0 disk /edata

Step 2 – Move MySQL DB

Use the following steps to move the MySQL DB from the default installation location to a new drive. Change /edata  to the new drive.

sudo systemctl stop mysql
sudo rsync -av /var/lib/mysql   /edata
sudo mv /var/lib/mysql /var/lib/mysql.bak

sudo vi /etc/my.cnf

Change datadir and any other variable that is referencing /var/lib/mysql

datadir=/edata/mysql socket=/edata/mysql/mysql.sock log-error=/edata/mysql/log/mariadb.log slow_query_log_file = /edata/mysql/log/slow-query.log

Add the OS Permissions for the new mysql location

sudo semanage fcontext -a -t mysqld_db_t "/edata/mysql(/.*)?"

sudo restorecon -Rv /edata/mysql

Start MySql

sudo systemctl start mysql

If you a closed system with no internet access BridgeGate will be unable to check for new versions of the software.

You will see an error message says trying to get latest service pack from internet every hour. [com.oidev.bridgegate.BridgeGateController] retrieveLatestServicePackLocation() unable to get LatestServicePackLocation from http://www.bridgegatedev.com/software/9.0/currentsplocation.html

This check can be disabled by adding CHECK_SVC_PACK=”FALSE” to the bridgegate.xml under the BRIDGEGATE_CLUSTER element.

<BRIDGEGATE_CLUSTER BIND=”192.168.*.*” FAILOVER=”FALSE” NAME=”BG-SMS” PING_RATE=”30000″ SP_DEPLOY_TIMEOUT_IN_MINS=”5″ CHECK_SVC_PACK=”FALSE” />

When BridgeGate is first started it check the connection to the database.  If you receive the following exception the version of MySQL has a parameter change.

[com.oidev.bridgegate.clustering.BridgeGateLoadBalancePolicy] checkDB() Error executing sql! java.sql.SQLNonTransientConnectionException: Cannot load connection class because of underlying exception: com.mysql.cj.exceptions.WrongArgumentException: The connection property ‘zeroDateTimeBehavior’ acceptable values are: ‘CONVERT_TO_NULL’, ‘EXCEPTION’ or ‘ROUND’. The value ‘convertToNull’ is not acceptable. at

Update the /bridgegate/conf/bridgegate.xml   Change zeroDateTimeBehavior=convertToNull  to zeroDateTimeBehavior=CONVERT_TO_NULL

<DATABASE_CONNECTION_POOL ACQUIRE_INCREMENT=”2″ AUTO_COMMIT_ON_CLOSE=”false” CHECKOUTTIME=”600″ DRIVER=”com.mysql.cj.jdbc.Driver” IDLETIME=”600″ IDLE_TEST_PERIOD=”300″ JDBCURL=”jdbc:mysql://localhost/bridgegate?useSSL=false&amp;autoReconnect=true&amp;useUnicode=true&amp;characterEncoding=UTF-8&amp;zeroDateTimeBehavior=CONVERT_TO_NULL&amp;serverTimezone=EST”   ….. />

The AS2, Applicability Standard 2 for EDI, is quickly becoming one of the most secure, reliable and popular methods for sending and receiving data over the internet.   The concept for AS2 involves sending data between two points via the web within a container or envelope created by the AS2, the created certificate and public and private keys keep the information secure.  Only a few components are necessary for an organization to utilize AS2: two servers to connect; internet access; and the data to be sent and received.  The AS2 server wraps or envelopes the data, using digital encryption and certificates, which allows the data to be transmitted securely over the internet.  To clarify the role of the certificate, public and private keys within AS2 transactions review the following definitions:

The Public Key: is used to encrypt and verify digital signatures. The public key is safe to distribute to your trading partners.  The trading partner will use this key to encrypt the data that will be sent to your AS2 server.

The Private Key: is used to decrypt, digitally sign and is always kept private and protected. This key is installed in your BridgeGate key store on the AS2 server.

The Certificate: much like a driver’s license, is used for identification purposes, identifying the issuer of the certificate, show expiry and give a unique number assigned to the certificate called a serial number.  Every certificate will have its own unique serial number

This explanation of the AS2 cert/public/private key relationship and how the AS2 is used to send and receive EDI.  When an AS2 certificate is created two keys are generated which are linked together by an algorithm, one is a Private Key and one is a Public Key.  The Private Key is stored in the BridgeGate keystore on the AS2 Server, while the cert along with the Public Key is sent to the Trading Partner. The keys are then used to access the data contained within the AS2 envelope.  The following is an example of a typical AS2 exchange between BridgeGate and A-TradingPartner:

AS2 Example – Typical AS2 Process between BridgeGate and A-TradingPartner

• EDI payload is encrypted using the A-TradingPartner cert/public key (on BridgeGate AS2 server)
• EDI payload is signed using the BridgeGate (Sender) private key (on BridgeGate AS2 server)
• AS2 connection is made to the A-TradingPartner AS2 server https://a-tradingpartner.com:10443 (on BridgeGate AS2 server)
• Payload contains a request to return an MDN, either sync or async (on BridgeGate AS2 server)
• AS2 IDs/Names are used to identify the AS2 relationship (on A-TradingPartner AS2 server)
• EDI payload is decrypted using the A-TradingPartner private key (on A-TradingPartner AS2 server)
• EDI payload has its digital signature verified using the BridgeGate cert/public key (on A-TradingPartner AS2 server)
• MDN is returned with a “processed” or “Decryption failure” or “Authentication, unable to verify signature…” status (on A-TradingPartner AS2 server)

How do I upgrade to BridgeGate 9.0?   http://www.bridgegatedev.com/documentation/getting-started/bridgegate-server/bridgegate-server-installation-2/bridgegate-serve…stallation-linux/

BridgeGate has a native Apache ActiveMQ Adapter built in the product.  If you are one an older build you may need to add the Adapter you to your bridgegate.xml for it to show up in the Workbench.

Add the following line to the bridgegate.xml at the top of <ADAPTER_LIST> <ADAPTER CLASS=”com.oidev.bridgegate.adapter.ActiveMQAdapter” NAME=”ActiveMQ”/>

You will then need to restart your BridgeGate server and workbench.

Note the default Context URL string is  tcp://ipaddress:61616

Webmin takes memory readings from top VIRT (Virtual) and is almost always noticeably bigger than RES (Resident). Webmin is reporting the virt value which includes memory shared with other processes (library code that is loaded into real memory only once but mapped into the virtual address spaces of multiple processes. i.e Java) and memory that is allocated but not yet used (it is available in the processes virtual address space, but no real RAM or swap pages have been allocated for it yet).

BridgeGate can be configured for mysql database failover with the following updates to the jdbc url in the bridgegate.xml

MySQL jdbc supports server failover. A failover happens when connection-related errors occur for an underlying, active connection.  ie Database down.  A connection using failover support works just like a standard connection: the client does not experience any disruptions in the failover process.

jdbc:mysql://[primary host][:port],[secondary host 1][:port][,[secondary host 2][:port]]...[/[database]]» [?propertyName1=propertyValue1[&propertyName2=propertyValue2]...]

The host list in the connection URL comprises of two types of hosts, the primary and the secondary. When starting a new connection, the driver always tries to connect to the primary host first and, if required, fails over to the secondary hosts on the list sequentially when communication problems are experienced. Even if the initial connection to the primary host fails and the driver gets connected to a secondary host, the primary host never loses its special status: for example, it can be configured with an access mode distinct from those of the secondary hosts, and it can be put on a higher priority when a host is to be picked during a failover process.

Update the jdbc url to include the primary database IP and then a comma list of secondary IP address.

jdbc:mysql://192.168.10.17,192.168.10.18/bridgegate? …..

Below is an example of the bridgegate.xml configured with a primary db on IP 192.168.10.17  and the secondary db on IP 192.168.18

<DATABASE_CONNECTION_POOL ACQUIRE_INCREMENT=”2″ AUTO_COMMIT_ON_CLOSE=”false” CHECKOUTTIME=”600″ DRIVER=”com.mysql.cj.jdbc.Driver” IDLETIME=”600″ IDLE_TEST_PERIOD=”300″ JDBCURL=”jdbc:mysql://192.168.10.17,192.168.10.18/bridgegate?useSSL=false&amp;failOverReadOnly=true&amp;useUnicode=true&amp;characterEncoding=UTF-8&amp;zeroDateTimeBehavior=CONVERT_TO_NULL” MAXCONN=”300″ MAX_STATEMENTS=”0″ MINCONN=”10″ PASSWORD=”ENC3AMq%2BPLK4Q%2Bzvhu2oJhQvw%3D%3D” USERNAME=”bridgegate”/>

MySQL also supports load balancing across DBs.

Update bridgegate.xml to use the mysql loadbalance feature. Append loadBalanceStrategy=bestResponseTime to the existing URL. For URL jdbc:mysql:loadbalance://192.168.10.88,192.168.10.89/bridgegate?useUnicode=true&amp;characterEncoding=UTF-8&amp;zeroDateTimeBehavior=convertToNull&amp;loadBalanceStrategy=bestResponseTime

More details can be found on the mysql site.  See below

https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-config-failover.html

BridgeGate uses a configurable polling setting in the BridgeGate.xml to control how often the File RTP service will poll.  The default value is 20 seconds.  To modify the default value, go to the BridgeGate.xml and change the following element:

<FILE WATCHER_SVC_RATE=”20000″/>

*******************************************

Importing a P12 (i.e.: PKCS12) Certificate Chain into a BridgeGate Java KeyStore (JKS)

*******************************************

Keytool path:   C:\bridgegate\java\bin\keytool.exe

Openssl path:   C:\bridgegate\utils\openssl\openssl.exe

P12 Certificate Chain:  C:\data\cert\Bridgegate_HUBCertificates.p12

BG Staging JSK KeyStore:        C:\data\cert\bridgegate.jks

*** Note:  The Alias used in the JKS does not need to match the Common Name (CN) of the Client System Key.  The more important thing is that the BridgeGate Java KeyStore (JKS) does not contain duplicate aliases.  ***

1) List and verify P12 Certificate Chain contents:

c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.p12

Enter keystore password:

*****************  WARNING WARNING WARNING  *****************

* The integrity of the information stored in your keystore  *

* has NOT been verified!  In order to verify its integrity, *

* you must provide your keystore password.                  *

*****************  WARNING WARNING WARNING  *****************

Keystore type: PKCS12

Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: Bridgegate_HUB

Creation date: Jul 11, 2014

Entry type: SecretKeyEntry

2) IF the P12 Certificate Chain file is not password locked, you will need to recreate is with a password:

*** Export you current certificate to a password less pem type.  Note:  Leave the ‘Import Password’ field empty in this step.

c:\bridgegate\utils\openssl>openssl pkcs12 -in C:\data\cert\Bridgegate_HUBCertificates.p12 -out C:\data\cert\export.tmp.pem -nodes

Enter Import Password:

MAC verified OK

*** Convert the password less pem to a new pfx file with password:

C:\bridgegate\utils\openssl>openssl pkcs12 -export -in C:\data\cert\export.tmp.pem -out C:\data\cert\Bridgegate_HUBCertificates.locked.p12 -name “Bridgegate_HUB”

Loading ‘screen’ into random state – done

Enter Export Password:

Verifying – Enter Export Password:

3) Confirm Alias name is new password locked P12 Certificate Chain.  Step 2 creates alias based on -name argument, if this is left out, the alias name can be “1”.

*** Confirm Chain length of 3 and the Owner/Issuer of each Certificate are in the proper order.  ****

c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12

Enter keystore password: ******

Keystore type: PKCS12

Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: bridgegate_hub

Creation date: Jul 14, 2014

Entry type: PrivateKeyEntry

Certificate chain length: 3

Certificate[1]:

Owner: CN=Bridgegate_HUB ClientSystem, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

Certificate[2]:

Owner: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

Certificate[3]:

Owner: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

4) Import the P12 Certificate Chain into your BridgeGate Java KeyStore (JKS).

**** Note: You can alter the Alias name with the -alias and -destalias arguments. ****

c:\bridgegate\java\bin>keytool -importkeystore -destkeystore C:\data\cert\bridgegate.jks -srckeystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12-srcstoretype PKCS12

Enter destination keystore password:

Enter source keystore password:

Entry for alias Bridgegate_HUB successfully imported.

Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

5) Verify the JKS contains the new Certificate under the correct Alias.

*** WARNING: This password field is displayed on screen as clear text!  ***

c:\bridgegate\java\bin>keytool -v -list -storetype jks -keystore C:\data\cert\bridgegate.jks > c:\data\cert\out.txt

Enter keystore password:  *********

While BridgeGate is logging transaction/workflow details to the database, if it experiences issues saving a SQL statement to the database the statements are saved in the following location and will be automatically retried every 20 minutes.

/bridgegate/server/sqlqueue.history

Using Hazelcast.xml for TCP-IP configuration: Set the CONFIG_FILE attribute value to the hazelcast.xml file.

The BridgeGate cluster is configured through the BRIDGEGATE_CLUSTER tag in the bridgegate.xml file.

CONFIG_FILE This attribute is not included by default and is not necessary. Hazelcast will use multicast by default. If TCP-IP needs to be enabled or additional configuration needs to be made ( like giving specific ip-addresses for different nodes ), this setting could be used. The value of this attribute should be the file path to hazelcast.xml . Example <BRIDGEGATE_CLUSTER BIND=”172.31.*.*” CONFIG_FILE=”/bridgegate/conf/hazelcast.xml” …. /> The sample hazelcast.xml file is below

<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.6.xsd" xmlns="http://www.hazelcast.com/schema/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <network>
      <port auto-increment="false">5701</port>
      <join>
          <multicast enabled="false"></multicast>
          <tcp-ip enabled="true">
    <interface>10.0.0.30</interface>  
    <interface>10.0.1.10</interface>
          </tcp-ip>
      </join>
  </network>
</hazelcast>
or
<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.6.xsd" xmlns="http://www.hazelcast.com/schema/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <network>
        <port auto-increment="false">5701</port>
        <join>
            <multicast enabled="false"></multicast>
            <tcp-ip enabled="true">
    <interface>10.0.0.30-40</interface>  
    <interface>10.0.1.1-10</interface>
    <interface>10.0.2.1-10</interface>
            </tcp-ip>
        </join>
    </network>
</hazelcast>

Multicast configuration for clustering auto-discovery is defined as:

                <multicast enabled="true">
                    <multicast-group>224.2.2.3</multicast-group>
                    <multicast-port>54327</multicast-port>
                </multicast>
            

To Turn on logging for BridgeGate clustering, this can be done from the Server Management Page and Server Log Tab inside it, from the BridgeGate portal.

Alternately, edit the file conf/log4j.xml file in the BridgeGate Home. Locate the element category with attribute name com.hazelcast. The priority value can be changed from OFF to INFO or DEBUG. Verify the bridgegate\bin\bg_service.conf contains the following -D options

wrapper.java.additional.26=-Dhazelcast.logging.type=slf4j

Or on Linux make sure the /bridgegate/bin/runbridgegate has the following JAVA Opt

JAVA_OPTS=”${JAVA_OPTS}-Dhazelcast.logging.type=slf4j”

                                <category name="com.hazelcast">
                                   <priority value="OFF"/>
                                   <appender-ref ref="HAZELCAST" />
                                </category>

BridgeGate uses the Tomcat web server for SSL.   A good resource can be found below

https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

SSL Can be configured by editing the /bridgegate/server/conf/server.xml   We provide several examples of SSL Configuration

Search for <Connector port=”8443″    The section will be commented out using <!–

The default SSL Port is 8443.  Most configurations have a firewall or load balancer in front of BridgeGate.   If BridgeGate has not system in fron to it you can change the value to “443”

By Default the same keystore for the BridgeGate is used for SSL.  You can either add the domian SSL Cert to the default keystore or create a new one with the certificate.

Note you can get a change in IP for PASV FTP Host if your port range has been limited.

When using PASV FTP you need to provide a large enough port range to accommodate the max concurrent usage.   Some Operating systems like Windows are slow to release unused ports that will cause the range to be exhausted causing the system to change internal IP address to create a new port range.

To Turn on logging of Bridgegate clustering you need to enable Hazelcast logging.  First verify the bridgegate\bin\bg_service.conf contains the following -D options

wrapper.java.additional.26=-Dhazelcast.logging.type=slf4j

Or on Linux make sure the /bridgegate/bin/runbridgegate has the following JAVA Opt

JAVA_OPTS=”${JAVA_OPTS}-Dhazelcast.logging.type=slf4j”

You then can enable it from the Server Management Page and Server Log Tab inside it, from the bridgegate portal. Alternately, edit the file conf/log4j.xml file in the Bridgegate Home. Locate the element category with attribute name com.hazelcast. The priority value can be changed from OFF to INFO or DEBUG.

<category name="com.hazelcast"> 
<priority value="OFF"/> 
<appender-ref ref="HAZELCAST" /> 
</category>

Effective BridgeGate Version 8.0.6, System Schedules will no longer be administered via the BridgeGate.xml. The System Schedules are now maintained via the Portal on the Administration>Server Management->BridgeGate System Schedules tab.

When I created a my Predefined Connection for my AS2 Server I get the following exception when I send a AS2 Message to the server.

02/06/17 13:53:11 DBPartnershipFactory: Partnership COMPARE searchValue[MYEDI] against partnerValue[MYEDIAS2] (case-insensitive))
com.oidev.as2.partner.PartnershipNotFoundException: Partnership not found: Partnership null Sender IDs = {as2_id=MYEDI} Receiver IDs = {as2_id=MYEDIAS2} Attributes = {}
                at com.oidev.as2.partner.BasePartnershipFactory.getPartnership(BasePartnershipFactory.java:28)
                at com.oidev.as2.partner.BasePartnershipFactory.updatePartnership(BasePartnershipFactory.java:48)

When configuring the AS2 Server make sure that if you are changing the name of the AS2 Identifier from the default it is also updated in the bridgegate.xml.   Note the AS2 Server has a single AS2 Identifier per server.  So naming it correctly the first time is important. You need to updated the bridgegate.xml  AS2_SERVER section to match (See below)       The default is “BridgeGateAS2”   Whatever you put in the bridgegate.xml must match the PDC created for the AS2 server.  More information can be found in the AS2 Installation

For example:  If your bridgegate server is running on port 8081 and you want the external URL to be     http://dev.bridgegatehealth.com     You can create a Virtual Host in apache to act as a proxy

<VirtualHost *:80> ProxyPreserveHost On ProxyPass        “/” “http:// YOUR_INTERNAL_IP:8081/” ProxyPassReverse “/” “http://YOUR_INTERNAL_IP:8081/” ServerName dev.bridgegatehealth.com </VirtualHost>

Many more options and details can be found on the httpd.apache.org website.

I applied the latest Service Pack and now my BridgeGate server will not start.  The server log is showing the following exceptions:

org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]

[org.springframework.web.context.support.XmlWebApplicationContext] Exception thrown from ApplicationListener handling ContextClosedEvent java.lang.IllegalStateException: ApplicationEventMulticaster not initialized – call ‘refresh’ before multicasting events via the context: Root WebApplicationContext: startup date [Tue Dec 20 11:34:21 MST 2016]; root of context hierarchy

Solution:   Something caused the Service Pack to not fully unzip.   Delete the contents of the

\bridgegate\server\webapps\ROOT folder and the ROOT.war  and manually unzip the service pack.

Start the BridgeGate server.   This should resolve your issues.

The default protocol can be changed by adding the following like to the bg_service.conf  service file located under  /bridgegate/bin directory

wrapper.java.additional.40=-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1

This is the root to the data archive backup directory.  When this archive schedule runs, it will take all data from the data_archive, older than the DATA_RETENTION_TIME as configured in your bridgegate.xml file, and zip it up and place it in the \bridgegate\data_history folder location.

 It is not configurable but you can delete these if you want. That just means that you will be unable to get back to older data_archive files if you ever had to.

 Server documentation

I was able to make the connection by installing the Java Cryptography Extensions (JCE) Unlimited Strength Jurisdiction Policy files.  

These files are not included in the standard Java deployments to comply with US export rules.  However, they can be downloaded from the Oracle site at the following URL: 

http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-plat-419418.html#jce_policy-6-oth-JPR

The zip file downloaded will contain two .jar files (local_policy.jar and US_export_policy.jar).  These files must be copied to the BridgeGate installations.   

Workbench: 

  C:\bgworkbench\java\jre\lib\security

Server: 

  C:\bridgegate\java\jre\lib\security

(Replace C: with the install drive for the software)

There should be files with the same names already in those directories — just overwrite the files that are there.  The server/workbench will have to be stopped to replace the files. 

If you have any questions, feel free to call me at (904)739-0300 x221. I will be happy to guide you through the steps. 

The answer is that there are several options, each with their own trade-offs. Let me explain the best options to you, and you can choose the best one for your environment. 

I.  Increase maxThreads

The server.xml is configured such that the HTTP connector on port 8080 has a setting maxThreads=”300″.  However, the AJP 1.3 connector, which is the connector from httpd (mod_jk), is configured with the default thread count.  Increasing this thread count will increase the number of transactions actually running in parallel at any given time, but it may cause additional memory to be used. 

Note that the memory size reported in either Task Manager or BridgeGate is not necessarily indicative of the actual amount of memory being used at any given time. This is due to the generational memory management of the Java Virtual Machine. Basically, the JVM may be holding onto 3.6GB of memory, but may be using only a small fraction of that at any given time. The only way to really be sure how much memory is being used is by attaching a profiling application, such as jvisualvm, jstat, or any of a number of other profilers. 

The bottom line is that this setting will increase concurrent processing, but may use additional memory to do so. 

II. Increase backlog

The other option is increasing the size of the “backlog” setting on the AJP connector. This setting is analogous to the “acceptCount” setting on the HTTP connector (see http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html). When all threads are in use, the system will stil accept up to this count of connections, which will wait for free threads to process. 

Increasing this setting would keep the connections from being refused, but each additional connection sitting in the queue will wait for processing. Depending on how long they wait, the time to process may be longer than your SLA will allow.  

Yes as long as you can access the DB via JDBC or ODBC

We saw lots of ephemeral sockets being created and destroyed, which overwhelmed Windows.  We were able to get rid of these errors by increasing the number of sockets available and decreasing the time they are in a TIME_WAIT state.  We did that by adding some keys to the registry: 

Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, add the following keys: 

– TcpTimedWaitDelay: 30 (Decimal)

– MaxUserPort: 8FFF (Hexadecimal)

This increases the number of available connections from 16K to 32K, and ensures that connections are only in a TIME_WAIT state for 30 seconds, rather than the default of 120 seconds.  

However, looking at the netstat command, I see 11,000 connections in the ESTABLISHED state connecting to DllHost.  Since you run all the connections sequentially, you probably also want to lower the size of your MSMQ connection pool.  In your bridgegate.xml, you should have the following entry: 

<MSMQ_POOL MIN_SIZE=”2″ MAX_SIZE=”4″ />

You may need to experiment with the min and max values for maximum throughput.  The defaults are 5 and 20, but there are many sockets opened per connection. 

FTP over SSH timeout is set using the following.

Go to the BridgeGate.xml and add the following TIMEOUT element to the existing FTP_CONFIG elements.

FTP_SSH_CONFIG TIMEOUT=”60000”
FTP_CONFIG TIMEOUT=”60000”

In BridgeGate Version 7 and 8, you can alter the file server/conf/web.xml: 

<!-- ==================== Default Session Configuration ================= -->
<!-- You can set the default session timeout (in minutes) for all newly   -->
<!-- created sessions by modifying the value below.                       -->
  <session-config>
      <session-timeout>30</session-timeout>
  </session-config>

The same setting exists in 6.0, but the file is jboss/server/bridgegate/system/jbossweb-tomcat55.sar/conf/web.xml

View full Server Config docs

Disabling SSL3 in BridgeGate  should be pretty straightforward.  The server/conf/server.xml file contains a block that describes the SSL port configuration. Specifically, there is a setting that indicates the protocol, which by default reads sslProtocol=”TLS”.  Apparently, this is not entirely true,because it will roll back to SSL3.  

To get around this, you must specify the enabled protocols.  You can set this using the sslEnabledProtocols setting in that block, as shown in this configuration:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
           maxThreads="150" scheme="https" secure="true"
           clientAuth="false"
           sslProtocols = "TLS" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
           keystoreFile="C:/certificates/keystore.jks"
           keystorePass="P@55w0rD"  />

This is slightly different in BridgeGate 6.  The sslEnabledProtocols configuration was added in Tomcat 7, but there is an undocumented similar setting for BG6.  In the jboss/server/bridgegate/system/jbossweb-tomcat55.sar/server.xml file, add the protocols option as in the following:

<!-- SSL/TLS Connector configuration using the admin devl guide keystore -->
<Connector port="8443" address="${jboss.bind.address}"
     maxThreads="300" strategy="ms" maxHttpHeaderSize="8192"
     emptySessionPath="true"
     scheme="https" secure="true" clientAuth="false" 
     keystoreFile="keystore.jks"
     keystorePass="password" sslProtocol = "TLS" protocols="TLSv1,TLSv1.1"/>

If you have openssl installed on your system, you can verify SSL3 is disabled by running the following: 

openssl s_client -ssl3 -connect  <host>:8443

While the following should work:

openssl s_client -tls1 -connect <host>:8443

We support transactional MSMQ, just not *external* transactions.  

There are two types of transactions with MSMQ.  There is a specific MSMQ transaction service, which we support.  Commit/Rollback is executed through a workflow Action item.  Microsoft also has a method of integrating with external transactions, which can tie the MSMQ transaction in with another transaction (such as SQL Server).  This uses something called DTC (Distributed Transaction Controller, I believe), and this is what we do not currently support.  

Given that the MSMQ access through our product is done through our project, I’m not sure how it would be triggering a DTC transaction, so this requires some additional investigation into the error. 

Modify the urlrewrite.xml located at \bridgegate\conf to have the rule.  Note make sure ampersands (“&”) properly encoded, as follows:

     <rule>
          <from>/report-856$</from>
          <to type="forward">/portal/executeworkflow?accountName=hsn&amp;wfGroupName=adhoc&amp;wfName=856trans_from_today</to>
    </rule>

 

Add the following to the bg_service.conf located in the \bridgegate\conf directory and restart the server.  Prepare yourself for lots of logging.

-Djavax.net.debug=all

Stage the Service Pack file to: /bridgegate/servicepack

(Note:   Change ownership of file if BG not running as root)        

> chown bgate:bgate /bridgegate/servicepack/bridgegateSP_10.0.XXXXXX.zip

Execute the following commands as root:

> ls /bridgegate/servicepack

> service bridgegate stop

> rm /bridgegate/server/webapps/ROOT.war

> rm -r /bridgegate/server/webapps/ROOT/

> rm /bridgegate/server/webapps/update.war

> rm -r /bridgegate/server/webapps/update/

> unzip -o /bridgegate/servicepack/bridgegateSP_10.0.XXXXXX.zip -d /
> chown -R bgate:bgate /bridgegate/server/*

> service bridgegate start

Add the following in the bg_service.conf file:

# Log Level for log file output.  (See docs for log levels)

wrapper.logfile.loglevel=DEBUG

wrapper.debug=true

This should output tons of info to the BridgeGateWrapper.log file.  Don’t leave it like this for long.

In BridgeGate just create a SendData with the email adapter and use the following table for the cell carrier. 

http://www.emailtextmessages.com/

Below is a way to fix an out of sync instance of MySQL Master-Master Replication.

This way does not require restarting the MySQL services on either instance and requires no file deleting.

The steps will also work with a MySQL Master-Slave replication setup.

The key change is the –master-data attribute in the mysqldump command from the master database.

 https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_master-data

 “Use this option to dump a master replication server to produce a dump file that can be used to set up another server as a slave of the master. It causes the dump output to include a CHANGE MASTER TO statement that indicates the binary log coordinates (file name and position) of the dumped server. These are the master server coordinates from which the slave should start replicating after you load the dump file into the slave.”

 ________________________________________

——————-

MySQL Master-Master Replication is broken.

Note: Replace the following values.

Good Server IP:                192.168.10.11

Bad  Server IP:   192.168.10.22

Good Server NAME:       GOODHOST

Bad  Server NAME:          BADHOST

MySQL UserName: MySQLUSERNAME

MySQL Password: MySQLPASWORD

Note: All of these commands can be run from the ‘Good Server’, if you open two separate Command Prompts.

Note: If you run the ‘show slave status\G’ command too soon, you may not get the expected result.  Re-run the command again to verify.

Note: Most of the time will be spent during importing the mysqldump in step 3.

——————-

1. On Both Servers

STOP BridgeGate service on both systems.

Disable BridgeGate service to prevent auto-restarting.

2. On the Good Server

Open a Command Prompt.

Note: If extra databases are being replicated, add them to the list: “–databases bridgegate bd1 bd2 bd3”

Note: Do not include the following databases: mysql information_schema, and performance_schema

————

e:

cd bridgegate\mysql\bin

mysql -h 192.168.10.11 -u MySQLUSERNAME -p

MySQLPASWORD

show databases;

exit;

mysqldump -h 192.168.10.11 -u MySQLUSERNAME -p –add-drop-table –quick –master-data –databases bridgegate  > e:\bridgegate\bg.all.sql

MySQLPASWORD

————

3. On the Rebuilding Server

Note: Open a Command Prompt.

Note: Expected output of ‘slave status’ is “Slave_IO_State: Waiting for master to send event”

————

e:

cd bridgegate\mysql\bin

mysql -h 192.168.10.22 -u MySQLUSERNAME -p

MySQLPASWORD

stop slave;

exit;

mysql -h 192.168.10.22 -u MySQLUSERNAME -p bridgegate < e:\bridgegate\bg.all.sql

MySQLPASWORD

mysql -h 192.168.10.22 -u MySQLUSERNAME -p

MySQLPASWORD

start slave;

show slave status\G

flush tables with read lock;

show master status;

————

4. On the Good Server

Note: Set the slave here to be in synch with Rebuilding Server. Use the file name and log position from the previous step.

Note: Expected output of ‘slave status’ is “Slave_IO_State: Waiting for master to send event”

————

mysql -h 192.168.10.11 -u MySQLUSERNAME -p

MySQLPASWORD

stop slave;

change master to master_log_file=’BADHOST-bin.??????????’, master_log_pos=???????????;

start slave;

show slave status\G

————

5. On Both Servers

Enable BridgeGate service.

Start BridgeGate service on both systems.

Execute transactions on either server to test replication of database.

Also, test for Active=True/False and Loadbalancing settings at this time.

Note: Expected output of ‘slave status’ is “Slave_IO_State: Waiting for master to send event”

After both servers are up and running, check the ‘slave status’ of both MySQL servers.

————

show slave status\G

————

I was thinking it would be cool to use BridgeGate as a reporting tool.  To do that I would need to have the workflow executed on Demand with a URL which I know can be done?

The other think I didn’t know is if a variable could be entered as part of the url or could be promoted. 

 I.E.  A report that would be configured to run by different catalog code and the user would provide the code.

— Answer —

The easiest way would be setting up a WF with the BridgeGateHTTP Adapter with ‘Enable Workflow to be Executed as a Service’.

Create New In-Values with the ‘Add to Workflow Session’ selected to receive the values you want to receive into the Workflow.

The URL Preview will add the new URL parameter for use.

http://[SERVER_URL]/portal/executeworkflow?accountName=samples&wfGroupName=sample1&wfName=test_wf&catalog_code=[SESSION_VALUE]

http://localhost:8080/portal/executeworkflow?accountName=samples&wfGroupName=sample1&wfName=test_wf&catalog_code=123456

*******************************************

Importing a P12 (i.e.: PKCS12) Certificate Chain into a BridgeGate Java KeyStore (JKS)

*******************************************

Keytool path: C:\bridgegate\java\bin\keytool.exe

Openssl path: C:\bridgegate\utils\openssl\openssl.exe

P12 Certificate Chain: C:\data\cert\Bridgegate_HUBCertificates.p12  (Replace BridgeGate_HUBCertificates with your file)

BG Staging JSK KeyStore: C:\data\cert\bridgegate.jks

*** Note:  The Alias used in the JKS does not need to match the Common Name (CN) of the Client System Key.  The more important thing is that the BridgeGate Java KeyStore (JKS) does not contain duplicate aliases.  ***

1) List and verify P12 Certificate Chain contents:

c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.p12

Enter keystore password:

*****************  WARNING WARNING WARNING  *****************

* The integrity of the information stored in your keystore  *

* has NOT been verified!  In order to verify its integrity, *

* you must provide your keystore password.                  *

*****************  WARNING WARNING WARNING  *****************

Keystore type: PKCS12

Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: Bridgegate_HUB

Creation date: Jul 11, 2014

Entry type: SecretKeyEntry

2) IF the P12 Certificate Chain file is not password locked, you will need to recreate is with a password:

*** Export you current certificate to a password less pem type.  Note:  Leave the ‘Import Password’ field empty in this step.

c:\bridgegate\utils\openssl>openssl pkcs12 -in C:\data\cert\Bridgegate_HUBCertificates.p12 -out C:\data\cert\export.tmp.pem -nodes

Enter Import Password:

MAC verified OK

*** Convert the password less pem to a new pfx file with password:

c:\bridgegate\utils\openssl>openssl pkcs12 -export -in C:\data\cert\export.tmp.pem -out C:\data\cert\Bridgegate_HUBCertificates.locked.p12 -name “Bridgegate_HUB”

Loading ‘screen’ into random state – done

Enter Export Password:

Verifying – Enter Export Password:

3) Confirm Alias name is new password locked P12 Certificate Chain.  Step 2 creates alias based on -name argument, if this is left out, the alias name can be “1”.

*** Confirm Chain length of 3 and the Owner/Issuer of each Certificate are in the proper order.  ****

c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12

Enter keystore password: ******

Keystore type: PKCS12

Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: bridgegate_hub

Creation date: Jul 14, 2014

Entry type: PrivateKeyEntry

Certificate chain length: 3

Certificate[1]:

Owner: CN=Bridgegate_HUB ClientSystem, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

.

.

Certificate[2]:

Owner: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

.

.

Certificate[3]:

Owner: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

4) Import the P12 Certificate Chain into your BridgeGate Java KeyStore (JKS).

**** Note: You can alter the Alias name with the -alias and -destalias arguments. ****

c:\bridgegate\java\bin>keytool -importkeystore -destkeystore C:\data\cert\bridgegate.jks -srckeystore C:\data\cert\Bridgegate_HUBCertificates.locked.p12-srcstoretype PKCS12

Enter destination keystore password:

Enter source keystore password:

Entry for alias Bridgegate_HUB successfully imported.

Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

5) Verify the JKS contains the new Certificate under the correct Alias.

*** WARNING: This password field is displayed on screen as clear text!  ***

c:\bridgegate\java\bin>keytool -v -list -storetype jks -keystore C:\data\cert\bridgegate.jks > c:\data\cert\out.txt

Enter keystore password:  *********

*******************************************

Importing a PEM formatted Certificate Chain into a BridgeGate Java KeyStore (JKS)

*******************************************

Keytool path: C:\bridgegate\java\bin\keytool.exe

Openssl path: C:\bridgegate\utils\openssl\openssl.exe

Cert working location: C:\cert\

PEM Files:

Root CA Certificate: RootCACertificate.pem

Modality (intermediate) CA Certificate: prodCertificate

Client System Certificate: Bridgegate_HUB.pem   (Replace Bridgegate_HUB with your pem file)

Client System Key: Bridgegate_HUB.key  (Replace Bridgegate_HUB with your key file)

*** Note:  The Alias used in the JKS does not need to match the Common Name (CN) of the Client System Key.  The more important thing is that the BridgeGate Java KeyStore (JKS) does not contain duplicate aliases.  ***

1) Obtain the following PEM files.

– Root CA Certificate

– Modality (intermediate) CA Certificate

– Client System Certificate

– Client System Key (PK)

2) Get the Common Name (CN) for the Client System Key.

c:\bridgegate\utils\openssl>openssl x509 -in c:\cert\Bridgegate_HUB.pem -signkey C:\cert\Bridgegate_HUB.key -noout -issuer

Loading ‘screen’ into random state – done

Getting Private key

issuer= /C=US/ST=TN/L=Nashville/O=ICA/OU=IT/CN=Bridgegate_HUB ClientSystem

3)  Create a P12 Certificate Chain file.

Each of the Certificate files is a text file. Create a blank file named chain.tmp and copy-and-paste the following order: ‘Root CA Cert’, ‘Modality (intermediate) CA Certificate’ and ‘Client System Cert’ into one file.  Replace the CN from step 2 in the -name argument below.  Be sure to create a password at the ‘Export Password’ prompt.  A password is required for the keytool in a following step.

c:\bridgegate\utils\openssl>openssl pkcs12 -export -in C:\cert\chain.tmp -inkey C:\cert\Bridgegate_HUB.key -out C:\cert\Bridgegate_HUBCertificates.chain.p12 -name “Bridgegate_HUB”

Loading ‘screen’ into random state – done

Enter Export Password: ***********

Verifying – Enter Export Password: ***********

4)  Verify the contents of the new P12 Certificate Chain file.  Step 3 creates alias based on -name argument, if this is left out, the alias name will be something like”1″.

*** Confirm Chain length of 3 and the Owner/Issuer of each Certificate are in the propper order.  ****

c:\bridgegate\java\bin>keytool -v -list -storetype pkcs12 -keystore C:\cert\Bridgegate_HUBCertificates.chain.p12

Enter keystore password: ***********

.

.

.

.

Alias name: Bridgegate_HUB

Creation date: Jul 11, 2014

Entry type: PrivateKeyEntry

Certificate chain length: 3

Certificate[1]:

Owner: CN=Bridgegate_HUB ClientSystem, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

.

.

.

Certificate[2]:

Owner: CN=uat CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

.

.

.

Certificate[3]:

Owner: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

Issuer: CN=ICA Root CA, OU=IT, O=ICA, L=Nashville, ST=TN, C=US

.

.

.

.

5) Import the P12 Certificate Chain into your BridgeGate Java KeyStore (JKS).

**** Note: You can alter the Alias name with the -alias and -destalias arguments. ****

c:\bridgegate\java\bin>keytool -importkeystore -destkeystore C:\cert\bridgegate.jks-srckeystore C:\cert\Bridgegate_HUBCertificates.chain.p12 -srcstoretype PKCS12

Enter destination keystore password:

Enter source keystore password:

Entry for alias Bridgegate_HUB successfully imported.

Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

6) Verify the JKS contains the new Certificate under the correct Alias.

*** WARNING: This password field is displayed on screen as clear text!  ***

c:\bridgegate\java\bin>keytool -v -list -storetype jks -keystore C:\cert\bridgegate.jks> c:\cert\out.txt

Enter keystore password:  *********

To enable TLSv1.2 to be used as the default, add the following to the bg_service.conf:

wrapper.java.additional.40=-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1

• Authentication : This specifies whether Authentication should be performed and if so what type.
  • NONE : No authentication will be performed by this BridgeGate Web Service.
  • BASIC : Choosing BASIC will reveal inputs for user name and password. These values will be stored in the workflow for comparison against values provided in the request as follows:
    • The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.
    • BridgeGate will look for ‘Username’ and ‘Password’ in the SOAP header.
    • The Username field is assumed to be plain text.
    • The Password field is assumed to be base64 encoded.
  • BRIDGEGATE : The BridgeGate Web Service will authenticate the values provided in the request against the BridgeGate Users as follows:
    • The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.
    • BridgeGate will look for ‘Username’ and ‘Password’ in the SOAP header.
    • The Username field is assumed to be plain text.
    • The Password field is assumed to be base64 encoded.
    • The username and password will be authenticated against the BridgeGate Users and the Users must have BridgeGate Web Service portal permissions.

We use a third-party library (Apache Commons Net) to control the FTP connection.  This library creates the socket connections and directly implements the FTP protocol (RFC 959).  

To check the passphrase for a key is correct:

openssl rsa -check -in keyfilename

To change the passphrase for a key:

openssl rsa -des3 -in keyfilename -out newkeyfilename

SFTP server is not accepting connections.

Status:                   Connecting to myserver… Response:             fzSftp started, protocol_version=6 Command:           open “user@myserver” 22 Command:           Trust new Hostkey: Once Command:           Pass: ********* Error:                     Authentication failed. Error:                     Critical error: Could not connect to server

Should there be any keys in the bridgegate.xml?

    <FTP_SSH_CONFIG SERVER_PORT=”22″ SSH2_DSA_HOST_KEY=”” SSH2_DSA_HOST_KEY_PASSWORD=”” SSH2_RSA_HOST_KEY=”” SSH2_RSA_HOST_KEY_PASSWORD=”” VFS_ROOT=”C:\\bridgegate\FTPServer\accounts\root”/>

Or is this where I have to setup the keys in the workbench? When we setup the 8.0  versions we used self signed certs, this time I’m using the .JKS previously created.

— Answer —

The SSH key elements are unrelated to the .JKS keystore.  If values are not included in those elements, keys are generated at startup.  Those keys are also not used for authentication.  The system should be connecting to BridgeGate (through Hazelcast) for authenticating SSH. 

Our BridgeGate server will not start. The first exception in the stack trace is this:

Caused by: java.net.BindException: Address already in use: JVM_Bind

 Which indicates that something is already using one of the ports you are trying to open.  Specifically (the next element up the chain):

Caused by: java.net.BindException: Address already in use: JVM_Bind <null>:80

 So, port 80 is in use by something that is not BridgeGate. Now, trying to find what is running on port 80:

netstat -ano | find “:80”

yields:

TCP    0.0.0.0:80     0.0.0.0:0     LISTENING     4

You may have IIS or another webserver running on this server.   We recommend installing Bridgegate Webserver on port 8080 

Review server configuration

You can run any Workflow from a browser, or an external program can call a workflow via an URL by executing the following URL to the BridgeGate server. For a detailed example of using an URL, refer to Sample 6 in the online documentation under Tutorials.

http://[BGSERVER]/portal/translate?accountName=[ACCOUNT]&wfGroupName=[WFGROUP]&wfName=[WFNAME]&userName=[USER]&password=[PASSWORD]& [KEY=VALUE]

An example of accessing a server:

http://www.mycompany.com:8080/portal/translate?accountName=samples&wfGroupName=sample1&wfName=PurchaseOrders&userName=sample&password=mypassword

BridgeGate™ allows applications within enterprises to communicate with each other as well as providing seamless data connectivity to external systems and applications.

You can execute a workflow from the BridgeGate Workbench or by using an URL. You can run any Workflow from the command line by executing the following command in a DOS Window or by using a programming language.

To Execute the Workflow on the computer (local host) where the BridgeGate Workbench is installed, Execute the Workflow by using the following command:

/bridgegate/utils/curl http://localhost:8080/portal/translate?accountName=samples&wfGroupName=sample1&wfName=PurchaseOrders&userName=sample&password=mypassword&KEY=VALUE

The optional [KEY=VALUE] will be added to the Workflow Session as SESSION_DATA. The KEY can be any alpha numeric text that is not one of the above reserved keys.

BridgeGate™ is written in Java and is able to run on any platform that supports the Java Virtual Machine. BridgeGate Server clusters very well with heterogeneous networks consisting of Windows and Unix/Linux/Solaris machines.

Check out our installation guide for more details.

BridgeGate™ is written in Java so it is capable of running on any environment that supports Java (such as Windows, UNIX/Linux, AIX, or Mac). For windows installations the supported version of Java is included in the installation. For Linux installations BridgeGate will the version of Java installed on the server. BridgeGate 8.0 requires Java 8