1

I used the make_certs.cmd from Domino App Dev Pack 1.0.12-2786 to create the Root self-signed certificate.

@REM Creates CA cert and private key
:create_root
    set LOG=CREATE_ROOT:
    if exist ca.key echo ca.key already exists, skipping&exit /B 0
    if exist ca.crt echo ca.crt already exists, skipping&exit /B 0

    call :log %LOG% Generate ROOT private key
    echo on
    openssl genrsa -passout "%ROOT_PASSWORD%" -des3 -out ca.key 4096 || exit /B 1
    @echo off

    call :log %LOG% Generate ROOT self-signed certificate
    echo on
    openssl req -passin "%ROOT_PASSWORD%" -new -x509 -days %ROOT_VALIDITY% -key ca.key -out ca.crt -subj "%ROOT_SUBJECT%" -sha256 || exit /B 1
    @echo off

    exit /B 0

However, I used to tutorial scripts to verify, it result the following error.

C:\Certs>openssl s_client -connect serv.org.com:3002 --quiet -CAfile C:\Certs\ca.crt

depth=1 O = Proton, CN = Proton Certificate Authority verify error:num=19:self-signed certificate in certificate chain verify return:1 depth=1 O = Proton, CN = Proton Certificate Authority verify return:1 depth=0 O = Proton, CN = 192.168.176.130 verify return:1 10090000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl\record\rec_layer_s3.c:309:

I have remove the --"Quiet" command, 04130000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl\record\rec_layer_s3.c:309:

What your meaning that verify return 19, it does not affect I used it as the SSL certificate for IAM Service at Pilot mode.

C:\Certs>openssl s_client -connect serv.org.com:3002 -CAfile C:\Certs\ca.crt
CONNECTED(00000188)
depth=1 O = Proton, CN = Proton Certificate Authority
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 O = Proton, CN = Proton Certificate Authority
verify return:1
depth=0 O = Proton, CN = 192.168.176.130
verify return:1
04130000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl\record\rec_layer_s3.c:309:
---
Certificate chain
 0 s:O = Proton, CN = 192.168.176.130
   i:O = Proton, CN = Proton Certificate Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 27 04:22:03 2022 GMT; NotAfter: Jun 29 04:22:03 2023 GMT
 1 s:O = Proton, CN = Proton Certificate Authority
   i:O = Proton, CN = Proton Certificate Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 27 04:22:03 2022 GMT; NotAfter: Jun 26 04:22:03 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFFTCCAv2gAwIBAgIQC09HzlVL87ipWFZQhJdh0jANBgkqhkiG9w0BAQsFADA4
...
-----END CERTIFICATE-----
subject=O = Proton, CN = 192.168.176.130
issuer=O = Proton, CN = Proton Certificate Authority
---
Acceptable client certificate CA names
O = Proton, CN = Proton Certificate Authority
Client Certificate Types: RSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512:RSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 3405 bytes and written 487 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID:
    Session-ID-ctx:
    Master-Key: 29ABAD62B56FDFDABC7C7DBFBE310BF2DF66F941D2DBAC31A9B02DD6B8C6DEC353116CABEB0FED3F056A6F8E084BAF01
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1657089585
    Timeout   : 7200 (sec)
    Verify return code: 19 (self-signed certificate in certificate chain)
    Extended master secret: yes
---

results keys and certificates of make_certs.cmd

At the Domino Server, there are related error message, shown in the screen.

[13B0:0009-1034] 2022/07/13 下午 07:38:52  PROTON: GRPC Error: No match found for server name: serv.org.com.
[13B0:0009-1034] 2022/07/13 下午 07:38:52  PROTON: GRPC Error: Handshake failed with fatal error SSL_ERROR_SSL: error:100000c0:SSL routines:OPENSSL_internal:PEER_DID_NOT_RETURN_A_CERTIFICATE.
[13B0:0009-1034] 2022/07/13 下午 07:39:50  PROTON: GRPC Error: No match found for server name: serv.org.com.
[13B0:0009-1034] 2022/07/13 下午 07:39:50  PROTON: GRPC Error: Handshake failed with fatal error SSL_ERROR_SSL: error:100000c0:SSL routines:OPENSSL_internal:PEER_DID_NOT_RETURN_A_CERTIFICATE.
[0384:0002-03C8] 2022/07/13 下午 07:40:04  AMgr: Error executing agent 'DeleteExpiredDocs' in 'iam-store.nsf'. Agent signer 'Domino Template Development/Domino': You are not authorized to perform that operation
[0438:0002-132C] 2022/07/13 下午 07:41:36  Admin Process: Searching Administration Requests database
[13B0:0009-1034] 2022/07/13 下午 07:43:31  PROTON: GRPC Error: No match found for server name: serv.org.com.
[13B0:0009-1034] 2022/07/13 下午 07:43:31  PROTON: GRPC Error: Handshake failed with fatal error SSL_ERROR_SSL: error:100000c0:SSL routines:OPENSSL_internal:PEER_DID_NOT_RETURN_A_CERTIFICATE.
Cora Kwok
  • 13
  • 6
  • What makes you think anything "failed to verify" here? `s_client` didn't _show_ you the final verify error code (as opposed to the per-step callback status) because you used `-quiet`, but **there's no indication here of any problem related to the certificate** or even the handshake -- only _maybe_ during data phase, and that depends on the SSL/TLS protocol which you omitted and possibly the application protocol which I don't know. – dave_thompson_085 Jul 06 '22 at 06:19
  • What your meaning is this error message I could ignore ? – Cora Kwok Jul 06 '22 at 07:17
  • 04130000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl\record\rec_layer_s3.c:309: --- – Cora Kwok Jul 06 '22 at 07:18
  • As I said `0A000126 ... unexpected eof ...` is data phase; whether you can ignore it for 1.2 depends on the application protocol, but it is NOT related at all to certificate verification. However **your second `s_client` is different**: it shows obviously different certs than the first one, and it _does_ show a cert-related error in the callback block (`verify error:num=19:self-signed ... chain`) which was NOT in the first one. Either the server has changed certs or you are using a different server, so now I have no way to know what should or should not work. And I'm going to sleep. – dave_thompson_085 Jul 06 '22 at 09:11
  • It is using the same ca.pem to do the verification. One with the --quiet and one without. I just change the command, no the certificate. – Cora Kwok Jul 13 '22 at 11:42
  • It's using the same CAfile to verify, but the SERVER is different -- in fact in v4 you've changed the port on both examples, which is likely to produce different certs, and do have different certs on the first example (but you screwed up the formatting) AND consistent with having different certs the first example now DOES have 'verify error:num=19' which it did NOT have before. You are making it progressively harder to understand what is actually happening and thus impossible to solve. – dave_thompson_085 Jul 13 '22 at 23:43
  • It is not the fact. – Cora Kwok Jul 14 '22 at 04:24
  • The server used may be different for the first time and my last edit of the questions. However, the result screen were from the same server, same command prompt, but only different was the commands, one with and one without quiet. – Cora Kwok Jul 14 '22 at 04:58

0 Answers0