Certificate passbolt

The root directory is separated because of the translation, the original is all together and the nginx -t shows a correct confirmation.
The problem I have is that I try to change a self-generated certificate in the installation with another one in PEM format plus the KEY that is validated and recognized within the domain of the company, and even after the certificate is loaded, the web browser recognizes it. The exception continues and the red cross as if it could not validate it correctly.
The main thing that interests me is to know if passbolt has any problem when changing a certificate for another or something else needs to be done, apart from changing it in the nginx configuration …

My apologies for my English …

Could be this: a certificate is generated by an “CA” or “Certificate Authority”. If a user’s browser does not know that CA, then the cert will be flagged as insecure.

This is normal behavior in browsers in 2019, when being served self-signed certs.

If I misunderstand, please elaborate more and I will try to help.

Additionally:

  • The key should go with the cert (not sure if nginx -t would catch that)
  • The domains listed on the cert should match the actual passbolt domain/subdomain (or have a wildcard, etc.)
  • Cannot be self-signed (use a recognized CA, like Let’s Encrypt or other)

I attempted to view the site, but it does not respond, so there is no way to see the certificate error.

But, no, I do not believe that any web server certificate changes are going to impact the passbolt configuration. It’s all in nginx.

Well, I think the problem could be that the server itself is not accepting the CA certificate of trust, since in the Chrome or Firefox browser, if you recognize the CA root certificate that we use at the company level, I will try to make some tests so that the server where the passbolt is recognized as trustworthy …

I report according to progress …

Another approach might be to try to make the .pem cert include both the public key AND the root (CA) certificate.

This log show CA

[root@itpb ~]# openssl s_client -connect itpb.gestamp.com:443
CONNECTED(00000003)
depth=1 DC = com, DC = gestamp, CN = Gestamp CAROOT
verify return:1
depth=0 C = ES, ST = Madrid, L = Madrid, O = GESTAMP SERVICIOS S.L., OU = SYS, CN = itpb.gestamp.com
verify return:1

Certificate chain

  • 0 s:/C=ES/ST=Madrid/L=Madrid/O=GESTAMP *
    S.L./OU=SYS/CN=itpb.gestamp.com

  • i:/DC=com/DC=gestamp/CN=Gestamp CAROOT*

    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIFwzCCBKugAwIBAgITMwAABFaXPSOPkUT8WgABAAAEVjANBgkqhkiG9w0BAQsF
    ADBHMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHZ2VzdGFt
    cDEXMBUGA1UEAxMOR2VzdGFtcCBDQVJPT1QwHhcNMTkxMDExMDcyNjI1WhcNMjEx
    MDExMDczNjI1WjB5MQswCQYDVQQGEwJFUzEPMA0GA1UECBMGTWFkcmlkMQ8wDQYD
    VQQHEwZNYWRyaWQxHzAdBgNVBAoTFkdFU1RBTVAgU0VSVklDSU9TIFMuTC4xDDAK
    BgNVBAsTA1NZUzEZMBcGA1UEAxMQaXRwYi5nZXN0YW1wLmNvbTCCASIwDQYJKoZI
    hvcNAQEBBQADggEPADCCAQoCggEBAO+yaNBRJU2CEfZeQZbdC9t6XfRjWQNlAYTg
    JP1qzOqRUYUD3X02ybFCPUOxbD8hLapWMAIiKl9zXchhCUDLofqwLCG0zwGll57G
    VXBvr4Q/9AtVqW7nYZRE6ilc32CfawTA8cf4TfF5Ug/FUD9DftruicMACHFEupi6
    2WMCHtSR87hL06r4daorlA2D5YQ9XoebfXI0+bxWy5bXi1WM5y+cntfra/965Sok
    z9Kv/8lFMw8HGA1m9xFcit7D9WRaKSeuzY1FTDQiqDK+L90FNW71jtduDLvdS9db
    zqsnZv8pW94FyrYNH6+HvA24E1JSkAJc1Hx6+aBmJ+aqLf1ZsicCAwEAAaOCAnQw
    ggJwMB0GA1UdDgQWBBSUyHVxmwYY2ZwLHEQEjkfOPxXzBzAfBgNVHSMEGDAWgBRv
    NZr+S3DACBTHM46eA+d4MInIKTCB1AYDVR0fBIHMMIHJMIHGoIHDoIHAhoG9bGRh
    cDovLy9DTj1HZXN0YW1wJTIwQ0FST09UKDEpLENOPUdFUy1DQVJPT1QsQ049Q0RQ
    LENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZp
    Z3VyYXRpb24sREM9Z2VzdGFtcCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9u
    TGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIHCBggr
    BgEFBQcBAQSBtTCBsjCBrwYIKwYBBQUHMAKGgaJsZGFwOi8vL0NOPUdlc3RhbXAl
    MjBDQVJPT1QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl
    cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Z2VzdGFtcCxEQz1jb20/Y0FDZXJ0
    aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw
    CwYDVR0PBAQDAgWgMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIKm2FSGrqQ+
    ht2HP4bHp0iDsqdTGoWLzC6DuadeAgFkAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMB
    BggrBgEFBQcDAjAnBgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMBMAoGCCsGAQUF
    BwMCMA0GCSqGSASD9WiwUAA4IBAQDVdX4gwWoblM98rlFsZ8+ZPoBHI3K5VLqA
    +ufE1bARTdIO/o7gD7cgu8uqI+ZLoo6+S8+qvTL2j0qFks3YhQueuD05PmDXnAu
    +zWUJ17AWggMZLzsWXep/HNrFbdDNFDQuT2sK1LbDv6QU/G/Z/3RIDOHA+zRKE2H
    WvgoVfodX1oRt2kS6DFfbL58kPiOc9prPE+P18AESc/XlKUgrnhcbhXp3yqWmgoF
    d/7xu1/9Gt7XL5ki8A4Lf+P0mQrWF9g10CQl7AhXKzhkV4e0qFks3YhQueu
    KhduQjztR987alDQuT2sK1LbDv6QU/
    -----END CERTIFICATE-----
    *subject=/C=ES/ST=Madrid/L=Madrid/O=GESTAMP *
    S.L./OU=SYS/CN=itpb.gestamp.com
    issuer=/DC=com/DC=gestamp/CN=Gestamp CAROOT

    No client certificate CA names sent
    Peer signing digest: SHA512
    Server Temp Key: ECDH, P-256, 256 bits

    SSL handshake has read 2154 bytes and written 415 bytes

    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 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: 52A055E4D35587F91D8DAA28C815ABF2525B0A002D35AC44B3C9D257AEC88844*

  • Session-ID-ctx:*

  • Master-Key: 8200D80B4EF4499F40E2AC4DB0F5FD085F8EA280F95BAE32F093730FC43BF5848F2F4660F48BDB6ACAD4C38DD8047FD1*

  • Key-Arg : None*

  • Krb5 Principal: None*

  • PSK identity: None*

  • PSK identity hint: None*

  • TLS session ticket lifetime hint: 300 (seconds)*

  • TLS session ticket:*

  • 0000 - a0 65 70 af 94 5b b1 8f-30 69 01 bd a7 ab 47 0e .ep…[…0i…G.*

  • 0010 - cb e6 1f 77 28 84 8d de-45 e9 d6 f5 f2 d3 9e 15 …w(…E…*

  • 0020 - 1f 97 84 1f 63 03 3d 82-5e 2d b4 9b 7e da 4d 7f …c.=.^-…~.M.*

  • 0030 - f3 be d7 a8 81 3a 87 4c-43 0f ec 5e 3d f9 90 b1 …:.LC…^=…*

  • 0040 - db 7f 62 b6 47 59 1c fa-f4 e6 10 b5 47 c4 67 4a …b.GY…G.gJ*

  • 0050 - 9d 78 4c 0b c8 23 d3 65-58 58 a1 d8 82 c9 0d a4 .xL…#.eXX…*

  • 0060 - 31 75 06 c8 4d 31 60 18-3e 82 bc 1c 60 ac ae 5d 1u…M1.>...…]*

  • 0070 - 95 5f c6 bb 66 20 46 8f-30 cc bf 7c 3d eb 1f bf ._…f F.0…|=…*

  • 0080 - 36 c8 b0 f9 df e7 13 28-2f f5 02 64 43 69 6f 2b 6…(/…dCio+*

  • 0090 - 25 a6 97 34 16 dc a1 ed-5c 50 3c f7 1f 8e da b6 %…4…\P<…*

  • 00a0 - 3f 3f fe e4 6d be c4 3a-9a e5 95 af 94 d1 ba 41 ??..m…:…A*

  • Start Time: 1572272530*

  • Timeout : 300 (sec)*

  • Verify return code: 0 (ok)*

I have also tried to put the crt and the key together and the red cross still appears in the browser … Certificate not valid

Hola @Witty!

If I understand it correctly: Once you have changed the certificates and restarted the nginx service on your Centos your client still shows you the old self signed certificate?

No, once the nginx service has bounced, the machine bounced completely, the company’s CA ROOT appears, as if it recognized the server and the DNS name that is itpb.gestamp.com, but the red cross continues in the browser , and is something that has me very clueless, and put the CA in
/usr/share/pki/ca-trust-source /
I passed the commands:
update-ca-trust enable
Etc, etc. but continue without relying on the certificate and continue the red cross …

UHmmm on Firefox Explorer show this error:
https://itpb.gestamp.com/auth/login

The certificate issuer of the other party is not recognized.

Strict HTTP transport security: false

HTTP public key pinning: false

Certificate Chain:

The CA Root cert (on its own) needs to be in the /etc/ssl/certs folder so the server can reference it when you note the “combined public cert/CA root” (noted above) and the public key in the nginx settings.

[root@itpb ssl]# cp -pr /usr/share/pki/ca-trust-source/gestamp.cer .
[root@itpb ssl]# pwd
/etc/nginx/ssl

[root@itpb ssl]# ll
total 12
drwxr-xr-x 2 root root 79 Oct 28 17:56 backup
-rw-r–r-- 1 root root 1348 Oct 28 15:12 gestamp.cer
-rw-r–r-- 1 root root 1706 Oct 11 12:57 itpb_new.key
-rw-r–r-- 1 root root 2057 Oct 11 12:53 itpb_new.pem
[root@itpb ssl]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@itpb ssl]# systemctl restart nginx
[root@itpb ssl]# systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2019-10-28 18:01:37 CET; 4s ago
Process: 7365 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 7362 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 7360 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 7367 (nginx)
CGroup: /system.slice/nginx.service
├─7367 nginx: master process /usr/sbin/nginx
├─7368 nginx: worker process
└─7369 nginx: worker process

Oct 28 18:01:37 itpb.gestamp.com systemd[1]: Starting The nginx HTTP and reverse proxy server…
Oct 28 18:01:37 itpb.gestamp.com nginx[7362]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Oct 28 18:01:37 itpb.gestamp.com nginx[7362]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Oct 28 18:01:37 itpb.gestamp.com systemd[1]: Started The nginx HTTP and reverse proxy server.

https://nginx.org/en/docs/http/configuring_https_servers.html

The server still needs to know the CA…if the CA ROOT is in /etc/nginx/ssl then you can do a symbolic link in /etc/ssl/certs:
ln -s /etc/nginx/ssl/gestamp.cer /etc/ssl/certs/gestamp.cer

Try that, see if it helps.

Yes, a browser is not going to know the certificate issuer unless you install it into the browser.

More importantly, do NOT combine the public key with the public cert.

Combine the CA Root and the public cert. The public key is private and the location is noted in the nginx config file.

I looked at the cert used for www.gestamp.com and it’s a wildcard: “*.gestamp.com” which means the same cert could be used for your server. You would also need the private key that goes with it, though.

Yes, only the one we use for the gestamp domain has a wild card and it is signed internally … Well I will continue investigating … Maybe use the wild card to see if it works …

It’s not signed internally, it’s signed by a recognized Issuer:
image

Which means it can be used as-is, if you have access to the private key that goes with it as well.

If you only need this site for internal use, you could start from scratch (not with the gestamp cert) and create a root, then an intermediary issuer cert, then the final cert. I’ve done this for MySQL before.
For example: https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309

Ok, if I think it would be better to see where the problem is

If I succeed notice …

Thank you very much for the help

752/5000
Hello, I finally made it

Part by part:
First remove the PEM private key
openssl pkey -in itpb.gestamp.pem -out itpb.gestamp.key
He asks me for the password we put
Enter pass phrase for itpb.gestamp.pem: xxxxxxx

Then once I have the key, I put the key in the nginx configuration
ssl_certificate /etc/nginx/ssl/itpb.gestamp.pem;
ssl_certificate_key /etc/nginx/ssl/itpb.gestamp.key;

And now I create a file where I put the certificate pass:
ssl_password_file /etc/nginx/ssl/itpb.pass;
(The same one I used to create the key)

Then I bounce and reload the service.

systemctl restart nginx
systemctl reload nginx
systemctl status nginx

I’m going to chrome, and BINGO! Certificate valid in green !!!

What a pleasure …
Thanks for the help

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.