SSL and AppDev Pack 1.0.8

HCL Domino Domino Forum
,
1

Really struggling with the SSL configuration of Proton.

Domino Server = Domino11/Kelros

Notes ID = Travis Hiscock/Kelros

Server has a wildard ssl cert *.life-etg.com working successfully for HTTPS (a proper cert issued by ESET).

Tried following all the AppDev Pack documentation, but all they talk about is self signed certs (which no one uses anymore).

Anonymous Proton access works perfectly.

I am referencing the wildcard SSL cert in the Proton Server config, and have created an internet cert and insered this is into my Person document.

Person Docment Internet certificate says "1. CN=*.life-etg.com/OU=Domain Control Validated"

my config.json file is all setup

Trying the ptest command "npm run ptest -- read domino11/names.nsf -q "form = 'server'" -p -i form,servername,netaddr_0,http_sslkeyfile,domain,administrator"

This Produces "code: 14, details: 'No connection established'"

and on the Domino Server Console I can see: "PROTON: Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED. [src/core/tsi/ssl_transport_security.cc:1233]"

If I try OpenSSL with 'openssl s_client -connect domino11.life-etg.com:3003 -cert thiscock.crt -key thiscock-open.key'

I get "Verification error: self signed certificate in certificate chain" - is this a red herring as it's all been built from the wildcard ssl cert, why is it thinking it's self signed?

HCL Support very slow on this, so I thought I'd see if anyone else has experienced this. I'm dreading getting onto the IAM bits later!

2

If this is an official certificate then openssl s_client -connect domino11.life-etg.com:3003 should be enough for a valid connection.

If this fails then the certificate seems not be installed correctly on Domino.

If it works with Browser then most common issue is that not the whole chain with intermediate certificates are installed in Domino keystore.

In Browsers this often work but not in programmatical access.

You should verify theat with given command the whole chain of certificates up to the root certificate is returned in correct order

3

Mathias

You were right about our Domino KYR files. They were incorrect on all our Domino Servers, despite working perfetly via Browsers.

The old one would indeed fail a SSL Checker test.

We built a new KYR file, and now it passes a SSL Checker test.

But I'm still really struggling though with ptest and the user certificate. No matter what I do,iy just never seems to work out.

openSSL now errors with:

unable to load certificate
2556:error:0909006C:PEM routines:get_name:no start line:crypto\pem\pem_lib.c:745:Expecting: TRUSTED CERTIFICATE

and ptest errors, as before with:

at processTicksAndRejections (internal/process/task_queues.js:77:11) {
code: 14,
details: 'No connection established',

Domino Server Console:

PROTON: Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED. [src/core/tsi/ssl_transport_security.cc:1233]

How did you build your user.crt that you loaded into your Person Document?

4

Both Travis and myself have now had a look at this and we are really struggling (which is awful considering I thought my knowledge of using OpenSSL was quite good).

The issue seems to be that how do you create the client certificate file that gets imported to a users person document in Domino when you already have a fully configured Domino server using a public certificate authority verified (GoDaddy Domain WildCard SSL in this instance) SSL Cert.

Any help on this is greatly appreciated.

5

Agree, configuring server and client certificates can be difficult. I won't try to point you to the documentation because I can see that you're using it.

Some important points that are not specifically covered in the documentation:

The proton server and client certificates do not need to be issued by the same CA that has issued the certificate for any of the other services in Domino. In this case the GoDaddy CA. In fact many public CAs do not issue client-style certificates.

This means that you need to have your own process for issuing client certificates for your applications that use Proton.

Can you describe the steps that you followed to make your client and server certificates?

6

Based on the other comments, I think you already found this out. The Person doc above has the server's certificate. I can tell this because the CN has '*.life-etg.com' which is typical of a server certificate.

The Person doc needs to have a certificate specific to the Domino user. This certificate can be issued by the same CA that created the proton server's certificate or a different CA.

If they are different CAs there are additional steps to establish trust between the two CAs.

My recommendation is to use the "make_certs" scripts included with the AppDev Pack. They are described here:
https://doc.cwpcollaboration.com/appdevpack/docs/en/proton-admin-tls.html#creating-certificates-and-keyfiles

7

Steve

In the end I used both of the scripts included in the AppDev Pack and gave Proton its own 'self signed' keyring.

All is working correctly now.

8

Glad it worked for you. One important correction though. The scripts create certificates from a "private certificate authority". They are not self-signed certificates. I understand your hesitation about using self-signed certificates, and these certificates are not self-signed. They are signed by a common certifier that also happens to be private to you and your organization. Your organization has control over the certificates it generates and who has access to them.

The reason you would want to have certificates signed by a "larger" certificate authority is because other produts, typically browsers, have built-in trust for them.

Steve

9

You can configure proton to use your "real" certificate but it does not need to be "real" since users will never go there in a browser.

If you use a real cert, you still have the issue of a cert for the users... which you would probably mint via a local CA. (you can use the same ca to mint a proton server cert too and they will share a common CA, making config easier... that's all i was getting at)

if you choose to use the real proton cert, be advised that you need to make sure that you include the root CA cert for the client certificate in the kyr file that proton will use. It needs to know how to trust the user cert that is presented. If proton is using the same CA as the client (as is the case with our makecert scripts) you do not need to import the extra CA because they are the same.

10

I do see your traffic on the support side and our support engineers have reached out for help with this issue.