Creating self-signed certificates for PCS

[steen.jensen]

After one year of trouble with PCS on Windows server & MS IIS  and certificates (Self signed & real certificate with trused root) and all other problems, we terminated the implementation activity and ditched both PCS and Prolaborate as useful products.
Those products are not mature enugh to be placed in ouer Enterprise datacenter together with 800 apps on 2000 servers serving about 55.000 users.
The Datacenter operational staff is laughing at the install and operating instruction, and is asking if this products are open source products with no active developers.... When I say that we have paid (5.500€)for this products, they just walk away laughing....

[qwerty]

I have to bookmark that. My customer (a large car manufacturer) is playing with the thought of going the PCS way. I never was fond of it (gut feeling).

q.

[Eve]

I have to bookmark that. My customer (a large car manufacturer) is playing with the thought of going the PCS way. I never was fond of it (gut feeling).

So you're so desperate to confirm your gut feeling that you'll save a single negative comment in a forum?

Unfortunately, I don't know what issues steen experienced. I don't know if they are related to Prolaborate or PCS or if they ever contacted support about their issues.

Even if you feel like you don't need WebEA or Prolaborate, I would still strongly recommend having EA users connecting via PCS instead of a direct database connection.

[qwerty]

Desparation is the wrong word. It's more confirmation that would fit. It's Sparx decision on how they make money. And it's the customers decision to give Sparx money for their products. Or not.

q.

[Modesto Vega]

After one year of trouble with PCS on Windows server & MS IIS  and certificates (Self signed & real certificate with trused root) and all other problems, we terminated the implementation activity and ditched both PCS and Prolaborate as useful products.
Those products are not mature enugh to be placed in ouer Enterprise datacenter together with 800 apps on 2000 servers serving about 55.000 users.
The Datacenter operational staff is laughing at the install and operating instruction, and is asking if this products are open source products with no active developers.... When I say that we have paid (5.500€)for this products, they just walk away laughing....

Thank you Steen for confirming that we are not alone. Our experience so far with configuring PCS is not far from yours. The insistence that OpenSSL, an open source product, should be used for certification/self certification most likely contributes to creating the impression that PCS is an open source product with no active developers.

I would still strongly recommend having EA users connecting via PCS instead of a direct database connection.

Perhaps over HTTP. But as long as the only (poorly) documented option to configure PCS to handle HTTPS connections involves using OpenSSL and a PEM file, instead of an installed certificate, I don't think I can concur with that recommendation.

Please note that some Windows OpenSSL distributions are identified as malware and the security policies of many organisations are likely to prevent the use of OpenSSL.

Lastly, I hope Sparx Systems pays attention to the experiences of their your customers and learns from it.

[Modesto Vega]

After one year of trouble with PCS on Windows server & MS IIS  and certificates (Self signed & real certificate with trused root) and all other problems

We have been reviewing the situation and wanted to clarify a couple of things.

• We are using two virtual servers for this. Server 1 hosts PCS, with Server 2 hosting both WebEA and WebConfig on IIS.
• We requested certificates for both servers and were given two certificates, one per server.
• Both certificates have a certificate chain with a root certificate and an intermediate certificate.
• The certificate for Server 2, the web server, does not give us any errors.
• It is only the certificate for Server 1, the PCS server, that gives us errors.
• The certificate for Server 1, the PCS server, had to be converted to a PEM format. One of the issues we have is that we do not know if the errors are the result of the conversion or something else

Lastly, the way this page, https://sparxsystems.com/enterprise_architect_user_guide/15.2/pro_cloud_server/cloud_server_ca.html, is worded in such that it screams self-certification, they are instructions to create a self-signed certificate with a self-signed root - i.e., the certifying authority. There is nothing in this page that explains the process of generating a request for a certificate that is part of a certificate chain and must be issued by a certifying authority external to the parties carrying out the installation of PCS.

I hope, perhaps in vain, the Sparx System could clarify how to generate a request for a certificate that is part of a certificate chain and must be issued by a certifying authority external to the parties carrying out the installation of PCS.

[Eve]

5. It is only the certificate for Server 1, the PCS server, that gives us errors.
6. The certificate for Server 1, the PCS server, had to be converted to a PEM format. One of the issues we have is that we do not know if the errors are the result of the conversion or something else

I'm going to assume that the problem is that the conversion is the problem.

It should look like this:

Code: [Select]

-----BEGIN CERTIFICATE-----
base64content
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
base64content
-----END RSA PRIVATE KEY-----
I suspect that you haven't exported the private key when converting the certificate, meaning the second section is empty.

Lastly, the way this page, https://sparxsystems.com/enterprise_architect_user_guide/15.2/pro_cloud_server/cloud_server_ca.html, is worded in such that it screams self-certification, they are instructions to create a self-signed certificate with a self-signed root - i.e., the certifying authority. There is nothing in this page that explains the process of generating a request for a certificate that is part of a certificate chain and must be issued by a certifying authority external to the parties carrying out the installation of PCS.

I hope, perhaps in vain, the Sparx System could clarify how to generate a request for a certificate that is part of a certificate chain and must be issued by a certifying authority external to the parties carrying out the installation of PCS.

The good news is the the certification chain is irrelevant to the request, and the process doesn't change at all. At most, you would see all of the counter signed certificates also appearing in the PEM file.

If your organization is already set-up with an appropriate certificate chain... You don't need the basic instructions that we have provided for people that don't have a clue about the process. Ask the people who give you certificates for a PEM encoded x.509 certificate and how to get your private key into that format.

[Modesto Vega]

It should look like this:

Code: [Select]

-----BEGIN CERTIFICATE-----
base64content
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
base64content
-----END RSA PRIVATE KEY-----
I suspect that you haven't exported the private key when converting the certificate, meaning the second section is empty.

The private key was exported when converting the certificate. The 2nd section is not empty. The certificate looks exactly like described above. Furthermore, other than 2 web browsers throwing the same error, an inspection of the invalid certificate using a web browser does not reveal anything obviously wrong with it, this is a big part of the problem.

If your organization is already set-up with an appropriate certificate chain...

The certificate chain is already set-up and must be working because the certificate we are using for WebEA and WebConfig works fine and gives no errors. The difference is that it gets installed into IIS "as is" without any conversion. As you said, this could indicate that the conversion is the problem.

Ask the people who give you certificates for a PEM encoded x.509 certificate and how to get your private key into that format.

We are working on it but since we are doing this with no support from Sparx Systems, despite paying from it, it is proving more difficult than expected.

P.S.: The support desk has all the details but they are not very responsive.

[Eve]

If you have the file server.pem with contents as described in the install directory that should be enough to get it going.

What error do you get in the log file when you start?

[Modesto Vega]

We can see several instances of the following lines in PCS logs:

Code: [Select]

[TRACE]:   Thread 11  Soap Listener started
[DEBUG]:   Thread 11  Client connected from ::ffff:xx.xxx.xx.xx
[DEBUG]: [::ffff:xx.xxx.xx.xx] SOAP 1.1 fault: SOAP-ENV:Server [no subcode]
"SSL_ERROR_SSL
error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"
Detail: SSL_accept() failed in soap_ssl_accept()
We only get this messages by setting the logging level to TRACE.

Both the web browser and Sparx EA give an invalid certificate error, invalid common name, when using the URL over HTTPS. PCS returns the certificate to the web browser and when we inspect it we cannot see anything obviously wrong with it. At least one of the 2 common names matches the URL.


[Edit]
P.S.: Forgot to add that PCS does create a secure server ports 443 and 805 and can bind and listen on both ports.

Code: [Select]

[DEBUG]:   Thread 7  Created secure server on soap port 443 (https)
[DEBUG]:   Thread 7  ATTEMPT Bind and listen on soap port 443
[SYSTEM]:  Thread 7  SUCCESS Bound and listening on soap port 443 (https)
[DEBUG]:   Thread 6  Created secure server on soap port 805 (https)
[DEBUG]:   Thread 6  ATTEMPT Bind and listen on soap port 805
[SYSTEM]:  Thread 6  SUCCESS Bound and listening on soap port 805 (https)
In terms of timelines, these lines appear before the errors above.

[timoc]

Just a +1 on the pain it takes to setup PCS, even more so with HTTPS. Even with the documentation supplied there is googling and trial and error. This is especially true when you come at it from the EA documentation side, when using PCS for RAS functionality.

[Eve]

[SYSTEM]:  Thread 7  SUCCESS Bound and listening on soap port 443 (https)
[SYSTEM]:  Thread 6  SUCCESS Bound and listening on soap port 805 (https)

There is no problem with your server certificate as far as PCS is concerned. That effectively means every attempt at help to this point has been going  in the wrong direction.

Both the web browser and Sparx EA give an invalid certificate error, invalid common name, when using the URL over HTTPS. PCS returns the certificate to the web browser and when we inspect it we cannot see anything obviously wrong with it. At least one of the 2 common names matches the URL.

I'm pretty sure multiple common names in a certificate aren't something you can rely on. What you need is "subject alternate name". I know how to create that using an OpenSSL certificate request, but I don't know if certificate requests are different for different SSL tools.

LDAP request

In OpenSSL you need a request like this:

Code: [Select]

[ req ]
default_bits       = 2048
default_keyfile    = serverkey.pem
distinguished_name = server_distinguished_name
req_extensions     = server_req_extensions
string_mask        = utf8only

[ server_distinguished_name ]

omitted

[ server_req_extensions ]

subjectKeyIdentifier = hash
basicConstraints     = CA:FALSE
keyUsage             = digitalSignature, keyEncipherment
subjectAltName       = @alternate_names
nsComment            = "OpenSSL Generated Certificate"

[ alternate_names ]

DNS.1  = servername
DNS.2  = servername.domain.local
IP.1     = omitted
IP.2     = omitted



[Modesto Vega]

Code: [Select]

[ req ]
default_bits       = 2048
default_keyfile    = serverkey.pem
distinguished_name = server_distinguished_name
req_extensions     = server_req_extensions
string_mask        = utf8only

[ server_distinguished_name ]

omitted #########

[ server_req_extensions ]

subjectKeyIdentifier = hash
basicConstraints     = CA:FALSE
keyUsage             = digitalSignature, keyEncipherment
subjectAltName       = @alternate_names
nsComment            = "OpenSSL Generated Certificate"

[ alternate_names ]

DNS.1  = servername
DNS.2  = servername.domain.local
IP.1     = omitted #########
IP.2     = omitted #########



Thanks Eve, in the OpenSSL certificate request configuration file what are you trying to convey with the word "omitted"?

[Eve]

Sorry, that is where the commonName is specified. The rest of it comes down to the location of the config I copied.

Code: [Select]

[ server_distinguished_name ]
countryName         = Country Name (2 letter code)
countryName_default = omitted

stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = omitted

localityName         = Locality Name (eg, city)
localityName_default = omitted

organizationName            = Organization Name (eg, company)
organizationName_default    = omitted

commonName           = Common Name (e.g. server FQDN or YOUR name)
commonName_default   = primaryservername

emailAddress         = Email Address
emailAddress_default = omitted

[Modesto Vega]

Using OpenSSL (with a configuration file specific to the certificate) to generate the CSR solved our PCS certification issues. This is most likely because they were no conversion steps.

My conclusions are:

1) For PCS, if certificates have to be issued by a certifying authority, it is best to generate the CSR request using OpenSSL. It is not a recommendation, it is the only way to do it.
2) Sparx Systems could greatly improve how PCS uses certificates
3) Sparx Systems could vastly improve the documentation by
   a) covering other certification processes not involving, and
   b) vastly improving this page https://sparxsystems.com/enterprise_architect_user_guide/15.2/pro_cloud_server/cloud_server_ca.html.