View source for OS4X Core - OFTP2 getting started

In order to use the most-actual communication protocol OFTP2, you have to investigate several options.

== Certificate ==
OFTP2 is based on X509v3 certificates with special options contained in them. When using such an OFTP2 certificate, you have to decide from which issuer (from which CA; Certificate Authority) you order your certificate. Many profit-oriented companies exist in the world, also non-profit organisations. The key thing on certificates is:
 '''Is the issuer trusted by my communication partner(s)?'''
So you have to deal with the question, who your provider of your OFTP2 certificate is. 

Every certified (by Odette) OFTP2 system on the market must be able to support a TSL, a list of CAs which are trusted by default. Odette is hoster of the most commonly TSL in the OFTP2 world. In this TSL, a growing number of CAs are included which every major OFTP2 installation should trust. So, if your certificate is issued by a CA included in the Odette TSL, you're on the best way for a seamless usage of your certificate.

== Security options ==
OFTP2 offers a wide range of security options, which are:
*encrypted TCP/IP communication, aka. TLS ("Transport Layer Security"; the successor of SSLv3)
*secure authentification
*file encryption
*file compression
*file signing
*signed EERPs ("End to End ResPonse"; file transfer acknowledgement)

Every single option is optional, but most commonly the TLS layer is the basis for a secure OFTP2 communication. Every option (except of the compression) can(!) be handled with a single different certificate, but most commonly the certificate used for every operation is the same. If you want an extremely complex situation, you can implement a configuration where different certifiates can be used for every single operation for every single partner. (''This is an recommendation: use one certificate for all operations. You'll ease up you administrative live.'')

In general there is a recommendation: the less security options you choose, the less overhead in administration and CPU and/or I/O power you need. Here's a view of what you need when using these options:
*TLS: configure a TLS server (and optionally: TLS client) certificate on your OFTP2 system
*secure authentification, file encryptioon, file signing, signed EERP: exchange certificate with partner, retrieve certificate of partner, configure your own and partner's certificate to be used for these operations.

The TLS-only usage lowers the administrative overhead, might be the best choice for most installations. If you need more security or traceable logging of files, you might need to consult if you need signing and/or encryption in any situation.

== External reachability ==
Your system should be available world-wide, so you want to be reachable on a single defined port, most commonly for TLS. This default port has the number 6619 and is named as "<code>odette-ftps</code>" in most modern operating systems. You need TCP communication, UDP is not supported by OFTP2. You only need this single port for incoming communication. For outgoing communication, the outgoing port is allocaed randomly, such as in every single socket-based communication software.

You can achieve the external availability in several ways, depending on your own network security policy:
*Install the OFTP2 server directly on a host which is connected to the internet; implement a local firewall on that system.
*Port-forwarding of the incoming port on a centralized internet access to your OFTP2 machine (where the server for TLS listens on a pre-defined port; default 6619).
*Implement a chain of forwardings from zone to zone via any routers, gateways of other network security solutions.
*Use the [http://www.os4x.com/products/os4x-smartproxy.html OS4X OFTP2 proxy], install the server in the DMZ, the client in an internal (or intermediate) zone, reachable from your internal network. Up to three network segments, each secured by firewall rules, are supported.

Most communication partners use a firewall in order to secure the environment. Your system may need a static IP address in order to be configured by the remote firewall. Most dynamic IP assignments (i.e. DSL lines with a lease time of about 24h) are often not supported.

== HTTP access ==
Many operation on security rely on actual information. Most ressources of these information are available online via http(s). These are:
*CRLs (certificate revocation lists): files issued by CAs, containing a list of certificates which are revoked.
*TSL: The list of trusted CAs is available online, hosted on a server at Odette.

Your OS4X installation needs access to these online ressources, especially the CRLs are updated frequently, mostly daily. OS4X tries to download these information regularly. In case of failure, OS4X logs this unsuccessful download try and retries in the next run.

You can give OS4X access to the HTTP(s) ressources either:
*via direct internet connection
*using a locally reachable proxy (see [[OS4X HTTP Proxy support|here]] and [[OS4X_Core_configuration#Proxy|here]] for documentation)

== DNS ==
Every communication partner may give you either a globally reachable IP address or (better) a hostname of his system. The latter option is more flexible if the server must be moved from one IP address to another, since IP address changes can be done in the underlying DNS system.

Your best choice to make your system available online is to create a DNS entry (i.e. a subdomain of your company's domain; like "<code>oftp2.mydomain.com</code>" or something similar).

== Time synchronization ==
Many security parameters rely on a correct local time setting. Every communication via TLS contains an information piece of the timestamp when the session is being initiated, also certificates and CRLs contain a field from when on they are valid and until when. Your system time and date must be exact. Use a time synchronization via a global server, such as NTP.