OS4X Core list of possible log entries

This list of possible log entries (both receive, send and system logs) gives you an overview of all logs that could appear and what they mean in detail.

The messages are listed in no special order. It's possible that this list doesn't contain all messages that can arise!

send log

unknown type of connectivity for entry ...

All sending processes try to obtain the medium of that partner from the configured partner table (see OS4X Core configuration#Partner table parameters). If no numeric value can be resolved to a configured medium, this message is logged. The misleading value is contained in this message.

sending of file '...' aka '..' aborted: partner has asked for an invalid restart position of ... kB while we offered ... kB

OFTP offers a restart mechanism for file transfers. In this errornous case, the remote side wants to use a bigger restart position than OS4X (as sender) proposed to use. According to chapter 5.3.4 - "SFPA - Start File Positive Answer" of RFC 2204, the restart position given by the remote (receiving) side must be equal or lower than the sender proposed.

sending of file '...' aka '...' aborted: partner has asked for an invalid restart position

OFTP offers a restart mechanism for file transfers. In this errornous case, the remote side wants to use a bigger restart position than OS4X (as sender) proposed to use. According to chapter 5.3.4 - "SFPA - Start File Positive Answer" of RFC 2204, the restart position given by the remote (receiving) side must be equal or lower than the sender proposed. In difference to the above message, this one appears AFTER the calculation of amount of credits to be sent in case of using the send acceleration.

restarting file transfer at position ... kB

The file transfer begins at the documented position (not at the beginning of the file).

sending of file '...' aka '...' aborted by user at position ... kB of ... kB

During transfer of the file, a user interrupted the transfer by sending the process a signal so the transfer and connection will be aborted.

sending of file '...' aka '...' aborted at position ... kB of ... kB: send queue entry removed

As a "last option", OS4X supports the deletion of send queue entries and recognizing in the active transfer process that "his" entry is removed during transfer. In this case, during updating the progress information, the send process checks the existance of the send queue entry. If not existant, the process aborts the file transfer and adds this message to the send logs.

sending of file '...' aka '...' failed at position ... kB of ... kB

A network or ISDN connection problem causes the physical or logical connection to be closed, causing this error message. The problem itself is logged in another message.

all send queue entries for this partner have been blocked because of connection problems

If connection problems to a partner exist (like physical line problem, wrong credentials, wrong SFID etc.), after the maximum send tries of a send queue entry ALL entries for that partner are blocked in order to save connection costs.

a send queue entry for this partner has been blocked because of sending problems

If a partners refuses the receipt of this specific file and the maximum send try count is reached, this file entry is blocked. All other file entries in the send queue remain in its original state.

Error creating connection BIO

For SSL/TLS secured TCP/IP connections, an internal handler is needed which is called "BIO". This "BIO" is not available here.

Error connecting to remote machine

When connecting to a remote partner via SSL/TLS over TCP/IP and the remote system doesn't answer, this message is logged.

Error connecting SSL object

An error occured during the SSL/TLS handshake with the remote partner.

openSSL error: peer certificate: ...

An error occured during the check of validity of the remote (partner's) SSL/TLS certificate. The error message (from openSSL) is printed out in this log entry.

OFTP ERROR: ESID received during filetransfer (normal termination)

During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this case, no error code was given by the remote side.

OFTP ERROR: ESID received during filetransfer (reason: ...)

During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this casean error code was given by the remote side and the textual interpretation is listed in the message.

error in verifying data ...

The verification process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in signing data ...

The signing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in decrypting data

The decrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in encrypting data

The encrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in compressing data

The compression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in decompressing data

The decompression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in hashing data

The hashing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

Hashing is normally done internally only (called in OS4X itself when a file is successfully received).

error in compressing signed data

The compression process of OFTP2 signed data failed. The used command, returncode and output is appended in the log message.

error in extracting certificate from automatic certificate delivery

During automatic certificate exchange of OFTP2, the remote certificate is extracted from a CMS package (a special file). During the extraction, an error occured.

reveived signed EERP from partner invalid: verification command returned with code ...

During verification of a signed OFTP2 EERP (end-to-end-response, something like a file confirmation), the OFTP2 internal signature verification process returned with a returncode which was not zero (the actual value is added to this message).

reveived signed EERP from partner invalid in field EERPDSN: raw content is '...'

During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPDSN, which is the virtual filename.

The EERP is not archived, as it is not valid.

reveived signed EERP from partner invalid in field EERPDATE: raw content is '...'

During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPDATE, which is the virtual file datestamp (format: YYYYMMDD, i.e. 20070516).

The EERP is not archived, as it is not valid.

reveived signed EERP from partner invalid in field EERPTIME: raw content is '...'

During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPTIME, which is the virtual file timestamp (format: HHMMSScccc, i.e. 1533530001).

The EERP is not archived, as it is not valid.

reveived signed EERP from partner invalid in field EERPDEST: raw content is '...'

During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPDEST, which is the virtual file destination SFID.

The EERP is not archived, as it is not valid.

reveived signed EERP from partner invalid in field EERPORIG: raw content is '...'

During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPORIG, which is the virtual file originator SFID.

The EERP is not archived, as it is not valid.

reveived signed EERP from partner invalid in field EERPHSH: raw content is '...'

During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPHSH, which is the virtual file hash (i.e. binary SHA1 or SHA256 hash).

The EERP is not archived, as it is not valid.

reveived signed EERP from partner invalid: could not execute verification command

The verification process of a signed EERP cannot be started.

reveived signed NERP from partner invalid: verification command returned with code ...

During verification of a signed OFTP2 NERP (end-to-end-response, something like a negative file confirmation), the OFTP2 internal signature verification process returned with a returncode which was not zero (the actual value is added to this message).

reveived signed NERP from partner invalid in field NERPDSN: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPDSN, which is the virtual filename.

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid in field NERPDATE: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPDATE, which is the virtual file datestamp (format: YYYYMMDD, i.e. 20070516).

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid in field NERPTIME: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPTIME, which is the virtual file timestamp (format: HHMMSScccc, i.e. 1533530001).

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid in field NERPDEST: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPDEST, which is the virtual file destination SFID.

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid in field NERPORIG: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPORIG, which is the virtual file originator SFID.

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid in field NERPCREA: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPCREA, which is the creator SFID of the NERP message.

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid in field NERPHSH: raw content is '...'

During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPHSH, which is the virtual file hash (i.e. binary SHA1 or SHA256 hash).

The NERP is not archived, as it is not valid.

reveived signed NERP from partner invalid: could not execute verification command

The verification process of a signed NERP cannot be started.

RemoteCAPI error: invalid authentification. Check environment variables CAPI_USER and CAPI_PASSWD

The configured RemoteCAPI authentification parameters are incorrect. This error message could also occur if the RemoteCAPI device (normally a BinTec Brick) is under heavy load.

ISDN CAPI error 0x.... while connecting to partner: ....

The hexadecimal and textually resolved error code explain what the reason of not connecting to a partner is. For easy reading, all known ISDN error codes are resolved into human-readable text (like 'user busy', 'no free line' or something like that).

ISDN CAPI error: no free line available on RemoteCAPI device (... controller(s) checked)

No more lines are available for outgoing calls on all your configured ISDN CAPI controllers. Check your installation, your incoming and outgoing channels (don't forget non-OFTP connections like PPP, isdnlogin etc.!).

connection aborted by user

An OFTP connection was aborted during the exchange of protocol information by receiving a signal.

OFTP ERROR: handled credit count is zero

During OFTP handshake, the credit count is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

OFTP ERROR: handled buffer size is zero

During OFTP handshake, the buffer size is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

OFTP NERP ...: remote problem with virtual file '...': ...

The remote partner claims that there is a problem with the given file on the partner's side. The reason code and text is appended in this message.

OFTP SFNA ...: sending file '...' (aka '...') failed: ...

The remote side doesn't accept the file that OS4X wants to send before transfer. The reason code and text is listed in the message.

ODETTE EFNA ...: ...

The end-of-file-transfer message contains an error. The error code and reason text is appended to this message. The file is not transfered correctly then.

ODETTE DISCONNECT ERROR ...: ...

The OFTP connection unexpectedly died with a remote connectin close with a given error (text interpretation is also contained in the message).

partner acknowledges receipt of virtual file '...'

Speaks for itself: the file is sent and received correctly.

OFTP2 session aborted: secure authentification required, no SECD message received by partner

In case of OFTP2 secure authentification, the partner was requested to start the secure authentification mechanism. In this errornous case, he didn't. You may enable this configuration parameter: OS4X Core configuration#allow unsecure OFTP 2 authentification or disable "use OFTP2 secure authentification" in the partner configuration.

OFTP2 session aborted: secure authentification required (by ourself), no SECD message received by partner

In case of OFTP2 secure authentification, the partner was requested to start the secure authentification mechanism. In this errornous case, he didn't. You may enable this configuration parameter: OS4X Core configuration#allow unsecure OFTP 2 authentification or disable "use OFTP2 secure authentification" in the partner configuration.

session aborted: invalid challange ('...' != '...')

The OFTP2 security mechanism contains an exchange of a challenge (20 bytes of random data), which is signed by the remote side and returned. The signed data field is checked and the original data. Here, the original data wasn't returned, but another data package. The OFTP2 connection is closed then.

session aborted: invalid challange (returncode of verifying command was not 0)

The verification process of the OFTP2 secure authentification mechanism returned a value non-zero, so the authentification was unsuccessful.

session aborted: secure authentification required (by ourself), no AURP message received by partner

In the protocol for secure authentification of OFTP2, no regular message (in this case: AURP) was received. The OFTP session has been closed.

rejected receive of file: invalid virtual filename '...'

The receipt of the given virtual file was denied because it contains invalid characters in its name. You may re-configure the following option to make it work the next time: illegal characters for virtual filenames

ISDN ERROR: disconnect

The ISDN connect was closed unexpectedly. The reason why is contained in another log entry.

successful poll to partner

The physical connection to a partner was established successfully.

unsuccessful poll to partner

The physical connection to a partner was not established successfully.

beginning transfer of file '...' (aka '...')

The outgoing transfer of a file to the partner begins.

sending file '...' (aka '...') failed: unable to open file

The outgoing transfer of a file failed because the file could not be opened. Check existance and permissions.

correct transfer of file '...' (aka '...') @ ... kB/s

The file was transfered correctly (at a given overall throughput) and the remote side confirmed the correct transfer only by size of the file (not the content!).

incorrect transfer of file '...' (aka '...'): ... (@ ... kB/s)

The remote partner doesn't confirm that the given file was transfered correctly (mostly a problem of file size, restart position, fault in byte count).

error connecting to partner: '...' (address: '...')

When trying to connect to a partner via TCP/IP, the remote side didn't answer. The error message is created by the operating system running OS4X, so it may vary from system to system.

OFTP error: no SSRM received

When connecting to a remote system, the OFTP protocol states that the called side has to send a message (SSRM) in order to state that it's an OFTP system. This special message was not sent, but something else was received. So, the physical connection was successfully made, but no OFTP server is answering.

wrong remote password (transmitted: '...', OS4X database value: '...')

When connecting to a remote partner, the OFTP credentials (password & SSID) are transfered and checked. In this case, the expected value from the remote side doesn't match the locally stored. For easy administration, you may just copy & paste the values to the partner configuration (if you know what you are doing).

wrong remote SSID (transmitted: '...', OS4X database value: '...')

When connecting to a remote partner, the OFTP credentials (password & SSID) are transfered and checked. In this case, the expected value from the remote side doesn't match the locally stored. For easy administration, you may just copy & paste the values to the partner configuration (if you know what you are doing).

OFTP protocol error: command contained invalid data

The remote side sent an invalid OFTP protocol message. This leads to an OFTP protocol violation and an abort of the connection.

OFTP2 ERROR: secure authentification needed, but partner doesn't support this feature. Either set flag 'OFTP2 allow unsecure authentification' in basic configuration or inform partner.

When awaiting OFTP2 secure authentification, the remote side doesn't support it. Either change the partner configuration or inform the partner to support it.

OFTP2 is not supported in this version of OS4X. Please upgrade OS4X and get a new license.

Stands for itself: in some special variants of OS4X, the OFTP2 protocol is unsupported, but recognized. In order to support it, upgrade the OS4X binary installation and the license.

receive log

restarting file transfer at position ... kB

The file transfer begins at the documented position (not at the beginning of the file).

receiving of file '...' aka '...' aborted by user at position ... kB of (approx.) ... kB

During transfer of the file, a user interrupted the transfer by sending the process a signal so the transfer and connection will be aborted.

receiving of file '...' aka '...' aborted at position ... kB of (approx.) ... kB: receive queue entry removed

As a "last option", OS4X supports the deletion of receive queue entries and recognizing in the active transfer process that "his" entry is removed during transfer. In this case, during updating the progress information, the receive process checks the existance of the receive queue entry. If not existant, the process aborts the file transfer and adds this message to the receive logs.

OFTP ERROR: ESID received during filetransfer (normal termination)

During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this case, no error code was given by the remote side.

OFTP ERROR: ESID received during filetransfer (reason: ...)

During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this casean error code was given by the remote side and the textual interpretation is listed in the message.

OFTP ERROR: no valid OFTP header found during file transfer (but character '...')

During a OFTP session, all commands are exchanged with a command header. In this errornous case, no known command header was found.

unsuccessful connect try from ISDN number '...'

A remote partner from the given ISDN number called OS4X, but discontinued the OFTP protocol. If a partner has this number configured, the log entry is a receive log entry, if no partner was found, this entry is in the system logs.

unsuccessful connect try from IP '...'

A remote partner from the given IP address connected to OS4X, but discontinued the OFTP protocol. If a partner has this IP address configured, the log entry is a receive log entry, if no partner was found, this entry is in the system logs.

error in verifying data ...

The verification process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in signing data ...

The signing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in decrypting data

The decrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in encrypting data

The encrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in compressing data

The compression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in decompressing data

The decompression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

error in hashing data

The hashing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

Hashing is normally done internally only (called in OS4X itself when a file is successfully received).

error in compressing signed data

The compression process of OFTP2 signed data failed. The used command, returncode and output is appended in the log message.

error in extracting certificate from automatic certificate delivery

During automatic certificate exchange of OFTP2, the remote certificate is extracted from a CMS package (a special file). During the extraction, an error occured.

malformed remote certificate request: message was not signed, it was compressed or signed EERP request was given

A wrong message was received for automatic certificate exchange. The special virtual filenames are reserved for automatic certificate exchange:

• ODETTE_CERTIFICATE_REQUEST
• ODETTE_CERTIFICATE_DELIVER
• ODETTE_CRL_REQUEST
• ODETTE_CRL_DELIVER

fulfilled remote remote certificate request by adding my local public certificate to the send queue

An automatic certificate exchange request is fulfilled by adding the local public certificate for this partner to the send queue in a special format.

something went wrong during remote certificate request

The automatic OFTP2 certificate exchange mechanism has a problem during reacting on a remote request. The complete error message, including command, returncode, parameters etc. is logged in another log message.

successfully read in automatic certificate delivery

The automatic certificate exchange of OFTP2 successfully imported a remote certificate.

successfully handled incoming file '...' (file was ...)

A file which was signed, compressed and/or encrypted was handled successfully (and is now available for further processing).

Error loading CA file and/or directory

When creating a SSL/TLS client or server, the CA file or CA directory could not be loaded. At least one of them must be defined and exist!

Error setting default CA file and/or directory

The default CA file or directory could not be set up by a SSL/TLS client or server of OS4X. Check the configured values: OS4X Core configuration#SSL/TLS_parameters

Error loading certificate from file '...': not in PEM format, file does not exist or invalid password supplied.

The local client or server certificate could nbot be loaded. Check the file, format, access, the password (if set). Maybe it could be expired.

Error loading certificate from file '...': not in PEM format or invalid password supplied.

The local client or server certificate exists, but is not readable (invalid format or invalid password). Check the content.

Error setting cipher list (no valid ciphers)

TLS is not available. This should never happen!

beginning transfer of file '...' (aka '...')

The outgoing transfer of a file to the partner begins.

NETWORK ERROR: disconnecting during transfer of file '...' at ... kB of (approx.) ... kB

The network link was shut down during the receipt of the file at the given position.

correct transfer of file '...' (description: '...') @ ... kB/s

The file was transfered correctly (at a given overall throughput) and the remote side confirmed the correct transfer only by size of the file (not the content!). The description is the OFTP2 UTF8 encoded description of the file, converted to the target character set configured at OS4X Core configuration#local character set

correct transfer of file '...' @ ... kB/s

The file was transfered correctly (at a given overall throughput) and the remote side confirmed the correct transfer only by size of the file (not the content!).

rejected receive of file: invalid virtual filename '...'

The receipt of the given virtual file was denied because it contains invalid characters in its name. You may re-configure the following option to make it work the next time: OS4X Core configuration#illegal characters for virtual filenames

no space for file '...' (... kB) left on filesystem '...'

The local filesystem for temporary and incoming data is not big enough to hold the file the partner wants to send. Make more space.

file '...' already exists

The local file already exists with the given filename in the incoming directory. Two options:

• Enable the date- and timestamp-appendix to the filename if you receive the same filename but you are sure they are different ones. This adds the stamps to the filename the partner sends. Parameter: OS4X Core configuration#append timestamp to received file
• Enable overwrite of incoming files: OS4X Core configuration#overwrite existing incoming files

wrong local SFID (database value: '...', transmitted: '...')

When receiving a file, OS4X searches for partner entries in the defined partner table. If more than one entry matching the parameters password, SSID and SFID exist (both originator and destination; local and remote), the last entry will be used. If the found entry doesn't match the local SFID value, this error message will be added. You may change the local SFID in the partner's configuration in order to receive files from this remote system.

wrong originator SFID (transmitted: '...', database value: '...')

When receiving a file, OS4X searches for partner entries in the defined partner table. If more than one entry matching the parameters password, SSID and SFID exist (both originator and destination; local and remote), the last entry will be used. If the found entry doesn't match the remote SFID value, this error message will be added. You may change the remote SFID in the partner's configuration in order to receive files from this remote system.

session aborted: secure authentification required (by ourself), no AURP message received by partner

In the protocol for secure authentification of OFTP2, no regular message (in this case: AURP) was received. The OFTP session has been closed.

wrong remote SFID (transmitted: '...', no entry found for combination with SSID, password and SFID)

If no entry exists for this remote SFID in the database, the file can not be received (because it cannot be assigned to any partner). Search and/or modify partner configuration.

partner acknowledges receipt of virtual file '...'

Speaks for itself: the file is sent and received correctly.

OFTP protocol error: command contained invalid data

The remote side sent an invalid OFTP protocol message. This leads to an OFTP protocol violation and an abort of the connection.

wrong remote password (is: '...', should be: '...')

When a remote partner is calling, the OFTP credentials (password & SSID) are transfered and checked. In this case, the expected value from the remote side doesn't match the locally stored. For easy administration, you may just copy & paste the values to the partner configuration (if you know what you are doing).

partner unknown for SSID '...' and password '...'

No partner at all was found for these OFTP credentials.

OFTP ERROR: handled credit count is zero

During OFTP handshake, the credit count is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

OFTP ERROR: handled buffer size is zero

During OFTP handshake, the buffer size is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

OFTP error: no valid SSID received

The expected SSID was malformed. The OFTP connection was closed then.

not updated cipher suite variable '...' of cipher suite '...' with new certificate delivery value because:

During an automatic certificate update, OS4X tries to insert new values for all configured cipher suite variables. If a partner uses a defined environment for special import rules (which is empty by default until to create it), all cipher suite variables are checked against that ruleset. If a rule forbids to import the new certificate delivery into this variable, it's displayed in the logs. This may have several reasons:

• this is wanted behaviour (mostly the case)
• the partner delivers the wrong certificate
• the partner updated his certificate policy and didn't inform you

In the last case, you should contact your partner and check the OFTP2 certificate settings in a bilateral way.

TLS error: no valid X509 certificate given in TLS handshake by remote partner

The TLS server process (the receive daemon process with the name "os4xrd_tcpip_tls") got an incoming connection with an invalid, unknown, not-trusted or even without an X509v3 certificate at all. This can have many causes:

• the client doesn't provide any certificate at all
• the provided certificate is revoked (another log entry will show this)
• the provided certificate is issued by an unknown CA
• the provided certificate includes a CRL URL which is unknown until this connect (the CRL will be added to the CRL list and will be updated in the next time slice of the send queue daemon)

system log

If no partner could be found for a specific receive or send log message, or if the message is that generic, the entry will be put into the system log.

Remote CAPI timed out (possible reboot of device). Aborting session.

As a feature request, a reboot or hangup of a RemoteCAPI device is now logged in the systems log for each active transfer. So, a possible reboot of a Brick during the transfer of multiple files results into multiple (the amount of open transfers) system log entries.

license invalid

Hopefully speaks for itself: the license or its content is invalid. Please obtain a valid license.

CURL error x while fetching CRL from URL [...]

OS4X is able to download files via HTTP and HTTPS in order to maintain its CRLs as actual as possible. In addition, the TSL handler updates the list of trusted certificates via a download of a signed XML file from a configured URL. If anything goes wrong, the error is displayed then. You may then check the URL manually, or check the optional proxy settings which has the documented behaviour.

OS4X database successfully actualized

OS4X updates its database schema automatically, if it is not deactivated. In addition, after an invocation of the automatic software update, OS4X updates the database schema forced. Every time this happens, this log entry is added after a successful update.

certificate verify error x

During a TLS connect, the receive daemon checks the certificate chain of the incoming connection in order to ensure security. If anything goes wrong in this process, it's logged with detailed information here.

Since the partner information could not be found, this log entry resides in the system log.

You must download a CRL for the CA of the certificate with the subject ...

During an incoming connection via TLS, the partner certificate chain contains a certificate with an unknown CRL. This CRL (if any is given) is added automatically to the CRL list, but not actualized during this TLS session. The next timeslice the send queue daemon detects an old or invalid CRL, it actualizes it. So your partner with the given certificate chain should connect right after the import of the actualized CRL. If no CRL is available online, you have to upload it manually via the OS4X 2 Core - CRL management.

successfully handled TSL XML content

The TSL updating mechanism succeeded in importing and actualizing all trusted entities of the Odette Trusted Service List XML file.

More details on TSL can be found here.

OS4X TSL: trusting new certificate with subject ...

OS4X added successfully a trust to an entity of the TSL from Odette. The trusted entity subject is display here.

More details on TSL can be found here.

TLS error during connect try from [IP or hostname]: peer did not return a certificate

During the TLS handshake the error occured, that the TLS client (your communication partner) didn't return a TLS client certificate when he was requested to do so. You may lower your security settings in "Configuration" -> "TLS" by disabling the option "TLS server: check client certificate validity".