Creating self-signed certificates for PCS

[Modesto Vega]

The following page https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_repository/cloud_server_self_signed_ssl.html recommends using the OpenSSL toolkit to create self-signed certificates for ProCloud Server. However, it does not recommend what binaries to download for Windows Server 2016 and does not mention any other alternatives.

Does anybody have any suggestions?

[Eve]

OpenSSL because that's what we've provided instructions for. Any version of OpenSSL that runs on Windows Server 2016 will be pretty much equivalent.

If you're after alternatives, try typing "create self signed certificate using" into your preferred search engine and seeing what suggestions come up.

[Modesto Vega]

OpenSSL because that's what we've provided instructions for. Any version of OpenSSL that runs on Windows Server 2016 will be pretty much equivalent.

I don't have a complain about the instructions. Looking at https://wiki.openssl.org/index.php/Binaries it is far from clear what binaries are 64-bit, compatible with Windows Server 2016 (or 2019), and with no external dependencies (possibly FireDaemon OpenSSL 1.1.1).

Having discussed this at length with our infrastructure team, we have abandoned self-certification as an option, it will result on errors.

 

[Modesto Vega]

This is starting to get seriously annoying, after going down the Certificate Authority (CA) route, we just found that this page https://sparxsystems.com/enterprise_architect_user_guide/15.2/pro_cloud_server/cloud_server_ca.html is littered with OpenSSL references.

We have installed a certificate issued by a CA on the server. The request was created following the instructions on https://knowledge.digicert.com/solution/SO29005.html. The pem file was created following this instructions http://blog.shawnhyde.com/post/2020/02/12/how-to-generate-a-self-signed-pem-file-on-windows-using-iis.

In a nutshell, PCS is  unable to create secure server on soap ports 805 (https) and (https).

Is there a way to do without using OpenSSL?

[ddrakos]

Hi,

maybe you should examine using Let's Encrypt certificates instead.

Kind Regards
Drakos

[Eve]

Yes, our examples for how to do things are based on OpenSSL. That's why it's recommended.

Any Windows binary for OpenSSL will do, as could OpenSSL on any platform. You can even uninstall it completely after you've generated a certificate.

If you want to use something other than OpenSSL, it just means that you need to find your own instructions to get the right certificates. I don't know what the right settings are to do it with IIS or any other cryptographic platform you could come up with.

If you look at your generated file, it needs to look like this.

Code: [Select]

-----BEGIN CERTIFICATE-----
Base64 string that you can share
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Base64 string that you shouldn't share
-----END RSA PRIVATE KEY-----


[Modesto Vega]

The certificate we were issued by our internal certifying authority is a cer file that looks like:

Code: [Select]

-----BEGIN CERTIFICATE-----
<...>
-----END CERTIFICATE-----

It does not contain the private key, which we have assumed it is stored on the server.

In order to obtain the private key, we have

• imported the certificate using the MMC's Certificate snap in
• exported the private key as a pfx using again the MMC Certificate snap in (the user carrying out the operation cannot export it as a pem file)
• converted the pfx to a pem using openssl

.

If we do not specify the -nocerts parameter we end up with.

Code: [Select]

Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: <...>
    friendlyName: <...>
    Microsoft CSP Name: Microsoft Software Key Storage Provider
Key Attributes
    X509v3 Key Usage: 90
-----BEGIN ENCRYPTED PRIVATE KEY-----
<...>
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
    localKeyID: 01 00 00 00
    friendlyName: ProCloud Server
subject=<...> = <...>, ST = <...>, L = <...>, O = <...>, OU = <...>, CN = <...>

issuer=DC = <...>, DC = <...>, CN = <...>

-----BEGIN CERTIFICATE-----
<...>
-----END CERTIFICATE-----

If we specify the -nocerts parameter we end up with

Code: [Select]

Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: <...>
    friendlyName: <...>
    Microsoft CSP Name: Microsoft Software Key Storage Provider
Key Attributes
    X509v3 Key Usage: 90
-----BEGIN ENCRYPTED PRIVATE KEY-----
<...>
-----END ENCRYPTED PRIVATE KEY-----
This does not appear to be an rsa key.

[Modesto Vega]

Just a follow up. We got some progress; the issue was that we needed Convert Private Key to PKCS#1 Format. We did this by using the following command:

Code: [Select]

C:\OpenSSL-1.1\x64\bin\openssl pkcs12 -in <filename>.pfx -nodes -nocerts -password pass:<your password>| C:\OpenSSL-1.1\x64\bin\openssl rsa -out <out file name>.key
Followed by

Code: [Select]

copy /b <cer file name>.cer+<out file name (from previous step).key server.pem
The remaining issue is that we get the following security alert:

“The identity of this website or the integrity of the connection cannot be verified.
[…]
The name on the security certificate is invalid or does not match the name of the site.”

How do we correct this, if at all possible?

[qwerty]

You can't. That because it's self-signed. Purchase a certificate from a trusted provider and you will no longer see the message.

q.

[Eve]

You can't. That because it's self-signed. Purchase a certificate from a trusted provider and you will no longer see the message.

Failing that, create an internal certificate authority and use that to sign the certificate. It's a substantially more complicated to set-up, but once you have you can use that authority for a number of different reasons and only need to add the one root certificate to configure trust for a variety of servers.

[qwerty]

I never thought about that (since I did not have the need for it) but sounds interesting. https://stackoverflow.com/questions/4312904/browsers-and-certificate-store explains it a bit.

q.

[Modesto Vega]

You can't. That because it's self-signed. Purchase a certificate from a trusted provider and you will no longer see the message.

q.

I never thought about that (since I did not have the need for it) but sounds interesting. https://stackoverflow.com/questions/4312904/browsers-and-certificate-store explains it a bit.

q.

qwerty, the certificate is not
1) a self-signed certificate,
2) has been issued by our internal certifying authority, and
3) is part of a certification chain - i.e., it is related to a root certificate.

You can't. That because it's self-signed. Purchase a certificate from a trusted provider and you will no longer see the message.

Failing that, create an internal certificate authority and use that to sign the certificate. It's a substantially more complicated to set-up, but once you have you can use that authority for a number of different reasons and only need to add the one root certificate to configure trust for a variety of servers.

Where are the instructions explaining how to set this up?

[Eve]

I never thought about that (since I did not have the need for it) but sounds interesting.

I found it fascinating. If I had the time I would try setting up an internal ACME server. (For those that don't know, that's the protocol that powers Let's Encrypt) I'd love to see PCS add support as an ACME client to help make certificates easier to set-up, maybe one day.

qwerty, the certificate is not
1) a self-signed certificate,
2) has been issued by our internal certifying authority, and
3) is part of a certification chain - i.e., it is related to a root certificate.

Where are the instructions explaining how to set this up?

If that's the case and you're still seeing the prompt for a bad certificate you need to make sure that root certificate is trusted. You've already shared the link that provides basic instructions for the places that may impact for the certificate stores most likely to impact Sparx software. https://sparxsystems.com/enterprise_architect_user_guide/15.2/pro_cloud_server/cloud_server_ca.html

[Modesto Vega]

The next hurdle on the HTTPS configuration of PCS is as follows.

We have installed a certificate issued by our certifying authority with
1) 2 CN entries in this order

CN=procloudserver.<fully qualified domain>
CN=<server name>.<fully qualified domain>

2) 2 DNS names on the Subject Alternative Name section, in this order

DNS Name=procloudserver.<fully qualified domain>
DNS Name=<server name>.<fully qualified domain>

When we navigate to <server name>.<fully qualified domain>,we still get an invalid certificate error, NET::ERR_CERT_COMMON_NAME_INVALID.

Is this error caused by the 1st CN entry not containing <server name>.<fully qualified domain>? Can ProCloud Server handle a certificate with 2 CNs and 2 DNS?

[Eve]

The good news is that PCS doesn't care what you put in there.

It can be done, but I don't know how to add alternate names in the ssl platform you're using to generate your certificates.