Certificate passbolt

Hello, after doing a passbolt installation in a virtual machine with Centos 7, I am trying to add a PEM type certificate with its key.
I added it to the nginx configuration, the certificate is signed within the domain of the company. But I can’t make it work, can you give me any clues?

cat /etc/nginx/conf.d/passbolt.conf
server {
#listen 80;
listen 443 ssl;
server_name itpb.gestamp.com;
ssl_certificate /etc/nginx/ssl/itpb_new.pem;
ssl_certificate_key /etc/nginx/ssl/itpb_new.key;
client_body_buffer_size 100K;
client_header_buffer_size 1K;
client_max_body_size 5M;

client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 5 5;
send_timeout 10;

root / var / www / passbolt / webroot;
index index.php;


Plz, Guys any ideas?

Can you provide more information? You say that it does not work, but don’t describe what is happening.

Also “root / var / www / passbolt / webroot;” should have no spaces, obviously, between the folder names.


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.


  • 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
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 *

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

    Server certificate
    -----END CERTIFICATE-----
    *subject=/C=ES/ST=Madrid/L=Madrid/O=GESTAMP *
    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

  • 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:

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

[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.


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:

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