This is really strange. Here is the error in the log file
2013-07-30T11:24:09.042+02:00 [00848 info 'task-12'] Reusing existing VIM connection to sv130 2013-07-30T11:24:50.087+02:00 [00848 info 'task-12'] successfully sent client thumbprint to helper: D5:BB:FD:1D:38:67:66:8D:3C:30:27:19:66:66:26:47:3C:F6:E5:E6 2013-07-30T11:24:50.321+02:00 [00848 info 'task-12'] got server thumbprint from helper: 51:82:8C:B6:F7:E7:29:B5:0A:D7:B5:AB:DC:FC:B0:17:55:3F:E5:B8 2013-07-30T11:24:50.321+02:00 [00848 info 'task-12'] Reusing existing VIM connection to sv130 2013-07-30T11:24:54.306+02:00 [00848 info 'task-12'] got remote helper VM IP address as 10.158.19.22 2013-07-30T11:24:54.306+02:00 [00848 info 'task-12'] Connecting to Converter Helper on 10.158.19.22:443 over TCP/IP over SSL --> 2013-07-30T11:24:54.306+02:00 [00848 info 'task-12'] Connecting to Converter Helper with retry, retryCount 600, interval 1 2013-07-30T11:24:54.337+02:00 [03508 error 'HttpConnectionPool-000000'] [ConnectComplete] Connect failed to ; cnx: (null), error: class Vmacore::Ssl::SSLVerifyException(SSL Exception: Verification parameters: --> PeerThumbprint: 1D:D8:6C:B1:61:6A:F7:D2:CC:45:A4:77:A7:61:98:14:FA:DA:59:65 --> ExpectedThumbprint: 51:82:8C:B6:F7:E7:29:B5:0A:D7:B5:AB:DC:FC:B0:17:55:3F:E5:B8 --> ExpectedPeerName: 10.158.19.22
The helper IP address received from the DHCP server is 10.158.19.22. It was successfully passed to the Converter Server (since it is in the log). It has also received the Helper Server X.509 certificate thumbprint 51:82:8C:B6:F7:E7:29:B5:0A:D7:B5:AB:DC:FC:B0:17:55:3F:E5:B8. However when trying to establish an SSL connection to the helper and it fails with SSL exception, stating the expected and the actual thumbprints do not match. The actual certificate thumbprint received from the Helper server is 1D:D8:6C:B1:61:6A:F7:D2:CC:45:A4:77:A7:61:98:14:FA:DA:59:65, and since it is different than the expected one, the connection fails at each retry and eventually the conversion fails.
What comes to my mind is, is it possible to have an IP conflict within your network and actually there is another server with an IP address 10.158.19.22? If it is the case and there is a service listening on port 443 on that server, this would explain the observed behavior.