Sync replication using SSL servers doesn't work

gusdpr · September 19, 2014

Good day Plastic SCM staff,

I have a problem regarding replicating two repositories using a SSL connection with Plastic SCM 5.0.44.600. Both repositories are in two different PCs running windows on my same network. One of the PC is the central server, it has a self signed certificate that has provent to work correctly since I have tested the following works fine:

+ Creating a workspace with SSL connection on the server itself (on a localhost SSL connection using the server's name per the certificate)

+ Direct client to server workspace using SSL connection (no local client repository involved). I can navigate the remote repository branches with the secure connection. Certificate installed properly when attempting to connect.

So I know I don't have problems communicating securely with the server with those configurations. However the problem arises when I try to create a repository on the client and then replicate what's inside the server's repository using a secure connection. I get the following error in the UI panel when I try to replicate:

"Error: The authentication or decryption has failed: myserver.yyy.zzz:8088"

Changing the server's address with port 8087 works without issue. So I'm suspecting there is a bug or configuration issue somewhere. Can you help me to figure out what's wrong? Unfortunately there is no documentation on how to setup the configuration I'm working on. You really need to work on creating much more accurate information I needed to read multiple forums to get this working, existing documentation is very old and doesn't help much with more complex scenarios (like using and generating pfx files with plastic, what to do with the certificate on the clients, etc).

* More info

My workspace selector on the client (which works without a problem):

repository "remote_repo@ssl://myserver.yyy.zzz:8088"

Regards,

Gus

samvanbrussel · September 19, 2014

I'm having exactly the same issue. I think the problem is you cannot confirm the remote server's identity and accept the ssl certificate through the replicate functionality. If the certificate was trusted, I think it would work. That's why I'm updating my certificate to verify this, but I have an open issue to be resolved first by the Plastic SCM team.

gusdpr · September 20, 2014

Hi Sam, thanks for sharing. Now I don't feel alone

Here you have the steps I did to create my certificate using openssl, it works without a problem (look at the end of the thread). See David's response on the same thread where he clearly says the current instructions are supposedly to be obsolete to favor using pfx files instead:

http://www.plasticscm.net/index.php?/topic/741-ssl-certificate-issues/?hl=openssl#entry3719

Do not follow the guide that was shared to you on your other thread to create the certificate, it just doesn't work creating it with the .NET SDK. I already tried myself, use openssl.

calbzam · September 29, 2014

Hi,

Thanks for the feedback. I will test your steps to create the certificates using openssl and we will update the documentation if it´s necessary.

Regards,

Carlos.

dist · September 29, 2014

Hi everybody,

I run into just the problem gusdpr encountered. Any news on this? Anybody with an idea where we go wrong?

Best,

Dirk

dist · September 30, 2014

Let machines run on Windows in UPWorking mode using the default certificate shipped with Plastic as well as shipped 'remoting.conf'. Use identical users and groups on both machines. Open port 8087 and 8088 on both machines via inbound rule.

serverA
- act as remote on LAN
- repository 'repA'
serverB
- local machine on LAN
- repository 'repB'

Then I observe the following on the command line:

> cm replicate /main@repA@ssl://serverA:8088 rebB@ssl://serverB:8088

Error: The authentication or decryption has failed.: serverA:8088

> cm replicate /main@repA@ssl://serverA:8088 rebB@serverB:8087

Error: The authentication or decryption has failed.: serverA:8088

> cm replicate /main@repA@serverA:8087 rebB@serverB:ssl://8088

...here we go...

> cm replicate /main@repA@serverA:8087 rebB@serverB:8087

...here we go...

This is, things work unless I talk to the remote on the SSL channel.

I am new to Plastic. Anybody here that can help me making sense of this observation?

Best,

Dirk

calbzam · September 30, 2014

Hi dist,

If a Plastic SCM client tries to connect to a Plastic SCM server using SSL, a message will pop up

asking to accept or reject the server certificate. If the client accepts the certificate, it will be

stored in the machine for further operations. Once the certificate is accepted, communication

will flow, but what happens when a server needs to talk with another SSL server?

If a Plastic SCM client tries to connect to a Plastic SCM server using SSL, a message will pop up

asking to accept or reject the server certificate. If the client accepts the certificate, it will be

stored in the machine for further operations. Once the certificate is accepted, communication

will flow, but what happens when a server needs to talk with another SSL server?

Installing the certificate on server machines

As the server does not have any interface to interact with the user and accept the remote server certificates, we have to manually install the remote certificates on the server machine.

If the Server machine is a Windows machine you can use the “certmgr.msc” tool to import the remote server certificate. It needs to be imported into the “Plastic Client” store:

If the Plastic SCM server is installed in a Linux machine the “cer” file must be copied to the "~/.config/.mono/certs/Plastic client/" directory.

Both Windows and Linux steps must be carried out by the user that is running the Plastic SCM server. So the “certmgr.msc” tool must be executed by the right user and the "~/.config/.” path must be for the correct user.

Regards,

Carlos

dist · October 1, 2014

Hi Carlos,

thanks for the helpful reply.

I logged into all the machines as the proper user and did a

> cm lrep ...

to trigger installation of the certificate. Then verified certificate installation using certmgr.msc.

The error persists. Any ideas?

Best,

Dirk

calbzam · October 1, 2014

Hello,

I´ve sent you an email with extended information.

Previously in the post, it was reported an issue generating the certificate with the .NET SDK (I haven´t reproduced it yet). In that case, please use openssl as @gusdpr explained to generate the certificate.

Regards,

Carlos

dist · October 1, 2014

Hello,

thank you for the information.

I followed the path described in the document but:

I used openssl to generate the PKCS#12 pfx-file
I did not install certificates manually but triggered Plastic into doing the installation via "> cm lrep ..."

Then I ended up with the error stated above.

As far as I can tell from the remoting.conf coming with Plastic5 the PKCS#12 pfx is the way to go. Right?

Best,

Dirk

dist · October 1, 2014

calbzam · October 2, 2014

Hi,

Could you check if the "remoting.conf" file in both servers and clients (stored in the server and client folders), have enabled the SSL channel?

Regards,

Carlos

dist · October 2, 2014

Hi,

both channels enabled on all machines yes. I checked the files on each machine and also run a "> cm lrep ssl://xxxx:8088" successfully when logged into the machine.

Best,

Dirk

The client/remoting.conf looks like this in all cases:

<system.runtime.remoting>

</clientProviders>

</channel>

</clientProviders>

</channel>

</channels>

</application>

</system.runtime.remoting>

</configuration>

dist · October 9, 2014

Hello everybody,

I am still stuck on this topic and would be happy about some attention.

The problem:

- do a plain install of plastic client and server on two windows machines

- run plastic server on both machines in UPWorkingMode

- create identical plastic user on both machines

- punch the necessary holes into the firewalls of both machines

- create a repository on both machines

- in order to install the default ssl certificates on both machines into the user cert store run:

> cm lrep ssl://<self>:8088

> cm lrep ssl://<other>:8088

- set up a sync view using ssl communication between both machines

I end up with: Error: The authentication or decryption has failed.

Anybody out there that can vote on?

1) works for me

2) I have the same problem

Any voter gets a big mental hug

All the best,

Dirk

calbzam · October 9, 2014

Hi,

I´m able to configure the same scenario. Let me guess what could be happening:

- If I run a "cm lrep" using the remote IP, I get this message

C:\Program Files\PlasticSCM5\client>cm lrep ssl://192.168.1.56:8088
WARNING: the secure connection hostname provided in the server
certificate doesn't match the server's hostname. This means that the
certificate was not issued to this hostname or that there is a network
configuration problem with this host.


- Certificate hostname: CN=triskelion
- Server hostname: CN=192.168.1.56

If I re-run the command, the WARNING is appearing again and again.

- If I run a "cm lrep" using the hostname, I don´t get this message because the certificate was issued for this hostname.

C:\Program Files\PlasticSCM5\client>cm lrep ssl://triskelion:8088
 1 default ssl://triskelion:8088

The same happens when configuring the sync view. You need to enter the same hostname that is stored in the certificate. If you use the IP or a different server alias, the SSL connection will not work.

Summary:

- Step 1: Run the "cm lrep" command and check that the WARNING message is not being shown.

- Step 2: Configure the sync view using the same server name as the previous command.

Regards,

Carlos

dist · October 9, 2014

Hi,

I am certain that we are using the "correct" hostname on command line and within the client. On both machines no customization of the Plastic Setup whatsoever was done. Still, the sync view does not work.

Also, in case of a hostname mismatch the client would spawn warning dialogs. This does not happen.

We are running: 5.0.44.608 - Segovia

Best,

Dirk

calbzam · October 10, 2014

Hi,

If you configure the sync view using a hostname that is not getting the "WARNING" message (running "cm lrep"), are you still getting the error?

Could you try running the "cm replicate" command instead? If a command works, the rest of the commands should also work.

The client GUI is is not probably showing the warning dialogs, just the "authentication or decryption has failed" error.

Regards,

Carlos

dist · October 10, 2014

Hi,

I get the error without any warnings when running "cm lrep".

Running "replicate" on the command line produces the very same error.

... and the GUI client did show the error in all cases where I expected it to show it ...

Best,

Dirk

gusdpr · November 9, 2014

Hi all,

I have tried using the newest Plastic SCM 5.4.16.619 (Nottingham) to see if this issue was solved. I still experience the same problem, however the server is a little more loud this time as well as the UI. These are the logs from both sides:

Local server:

2014-11-08 16:37:40,703 00000000-0000-0000-0000-000000000000 NT AUTHORITY\SYSTEM at GUS-PC ERROR Operations - OnError catching exception The authentication or decryption has failed.: zzz.yyy.com:8088. Internal: Channel SSL UI is not initialized

Remote server:

2014-11-08 16:35:44,335 (null) NT AUTHORITY\SYSTEM at (null) INFO Channel - conn 268. Authentication failed because the remote party has closed the transport stream.

Carlos, can we get some help to figure out what does "SSL UI" means for Plastic?

Thanks,

Gus

gusdpr · November 18, 2014

Carlos or other Plastic staff, we really need help here. I really like a lot using Plastic but setting up a secure connection with a DVCS environment has turned into an endless circle (please see the above comments). Looking into the web shows only outdated documentation and no clear steps on how to do this with a DVCS. Please advice.

Regards,

Gus

pchieffo · November 18, 2014

I'm seeing the same problem. I've updated my certificates per the instructions given me from Codice, I have no certificate errors or warnings, I can connect to and navigate repositories on the remote machine, but I can't replicate, create or use the proxy cache. I'm getting the same authentication errors as the other posters.

calbzam · November 18, 2014

Hi,

I´m able to reproduce the issue when using the sync view. We are going to review it and fix it asap, but anayway using the Branch explorer or the command line, it should properly work:

- Command line: cm replicate br:/main@default@localhost:8087 repoRemote@ssl://remoteServer:8088

- Branch explorer --> right-click --> replicate: Remenber that you should enter something like:"ssl://serverName:8088" in the replication dialog of the remote server (If don´t enter the protocol, you will not ble a to perform the replication).

Regards,

Carlos

gusdpr · July 18, 2015

Hi Plastic SCM staff, Carlos,

I started this topic a while ago, now that I finally I decided to pay my own Plastic monthly subscription I tried to do exactly the same thing as described in my first post. Unfortunately this problem persists!

Using sync replication doesn't work with self signed certificates. However, creating a workspace by setting the "WorkspaceServer" in client.conf to point to the server by using ssl:// and port 8088 works perfectly fine, this shows the ssl connection is done successfully using this mode. Unfortunately this is not optimal for me and my team since we work in distributed mode (not centralized) so we need the replication functionality working with an encrypted connection and a self-signed certificate.

The error that is shown in the sync replication window says "Error: Only the server administrator can accept a certificate on the server", this is shown after I try to replicate and a pop-up window says if I want to accept the certificate, pressing "Yes" shows the error (running Plastic with Administrator privileged makes no difference at all on Windows 7). The error makes no sense after trying with administrator access.

Here is the server error log, it shows the real problem, the certificate was rejected because is not signed by a CA authority:

2015-07-17 21:13:57,301 00000000-0000-0000-0000-000000000000 NT AUTHORITY\SYSTEM at MY-PC INFO Channel - The certificate 1873BLAH has been rejected by the user
2015-07-17 21:13:57,301 00000000-0000-0000-0000-000000000000 NT AUTHORITY\SYSTEM at MY-PC INFO Channel - Rejected certificate validation info:
Sender: System.Net.Security.SslStream
Certificate:
    SHA1: 1873BLAH
    MD5: 790MEH
    Subject: CN=aaa.ccc.com, O=theserver, S=CA, C=US
    Issuer: CN=aaa.ccc.com, O=theserver, S=CA, C=US
    Expiration: 11/18/2018 12:43:06 AM
    Version: 3
Chain:
    Policy:
      Revocation mode: NoCheck
      Revocation flags: ExcludeRoot
      Verification flags: NoFlag
      Verification time: 7/17/2015 9:13:57 PM
    Status lenght: 1
      * Status: UntrustedRoot
SslPolicyErrors: RemoteCertificateChainErrors

2015-07-17 21:13:57,301 00000000-0000-0000-0000-000000000000 NT AUTHORITY\SYSTEM at MY-PC ERROR Operations - OnError catching exception [An error occurred processing the request. No more information is available. Please, check the logs to get more information.] - Plastic server version: 5.4.16.666
2015-07-17 21:13:57,301 NT AUTHORITY\SYSTEM at ERROR ExceptionTracerSink - Dumping in-transit exception:An error occurred processing the request. No more information is available. Please, check the logs to get more information.
2015-07-17 21:13:57,301 NT AUTHORITY\SYSTEM at INFO ChannelCall - recb: 1419|rect: 0|sentb: 3557|sendt: 0|prt:      32|th:   16|dest:   0|mt:      32|sert:   0|zip:   0|      10.0.0.169|GetReplicationSyncStatus
2015-07-17 21:13:58,970 00000000-0000-0000-0000-000000000000 NT AUTHORITY\SYSTEM at MY-PC ERROR Operations - OnError catching exception [Only the server administrator can accept a certificate on the server.] - Plastic server version: 5.4.16.666
2015-07-17 21:13:58,970 NT AUTHORITY\SYSTEM at ERROR ExceptionTracerSink - Dumping in-transit exception:Only the server administrator can accept a certificate on the server.

Further more, adding the self signed certificate as a CA and in the Plastic Client certificate folders using certmgr has absolutely no effect in this case, the same pop-up window is shown asking if I want to install the certificate and pressing yes makes the error happen on all cases.

Please see the attached screenshots of the issue showing the error and another one showing using a non-distributed (centralized connection) workspace works without issues. This shows there is a possible bug in the sync replication functionality which has not been solved yet.

Please fix this problem, it's been quite a while since this was reported . I'm using Plastic 5.4.16.666 - Barcelona at the moment.

Regards,

Gus

gusdpr · August 4, 2015

I contacted Plastic support and they helped me to resolve the problem. Quoting Manuel from Codice software:

"I think the issue is because the local Plastic SCM server is trying to automatically install the remote server certificate. This is only possible if you are the local 'Plastic SCM Server root' which is the repository server owner.

It's always a good idea to change the default repository server owner to yourself if you are working distributed so you will have full control of your repository data.

In order to do it: open the repositories view, right click in any of your local repositories and select "Repository server permissions", at the ACL dialog change the owner to yourself.

After doing that retry the replication operation."

To create your self-signed certificate follow the following instructions:

http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/

Then to convert the crt file generated from the instructions above to a pfx follow the next steps:

http://www.networkinghowtos.com/howto/convert-certificate-file-from-crt-to-pfx-using-openssl/

All the instructions use OpenSSL and I confirm they work

Hopefully this helps everyone who had this issue before.

Thanks Plastic staff!

Gus

manu · August 11, 2015

Thank you Gus for posting the answer!

Hope it helps to others!

Sync replication using SSL servers doesn't work

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in