Observation and Question about "--must-staple" and nginx's "ssl_trusted_certificate" r.h.s. value

Server
7

ssl_stapling_verify is set to on. Complete setup, with ssl_trusted_certificate omitted, is below.

I guess that ssl_trusted_certificate is only required and referenced if NGINX can not find the top level certificate. Decoding the intermediate certificate (there is only one) shows:

sudo openssl x509 -in /etc/letsencrypt/live/go-oio.com/chain.pem -text -noout
...
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
...

Checking in the cert directory:

ls /etc/ssl/certs | grep DST
DST_ACES_CA_X6.pem
DST_Root_CA_X3.pem

it is there - DST_Root_CA_X3.pem - the required top level certificate. It is reasonable to assume that NGINX knows to look in /etc/ssl/certs on my setup. The only alternative would be that it was failing to verify which is unlikely.

Another question is whether certbot-auto informed NGINX where to find the top level certificate as part of the certificate installation. Apparently it did not do so via ssl_trusted_certificate, but maybe there are other ways.

EDIT: After reading mnordhoff's reply, I recalled that in general practice OCSP is only used between the bottom and the first intermediate. If that is also the case the action performed when "ssl_stapling_verify on" is set, then a simpler explanation is that NGINX found the first intermediate as the second certificate of _fullchain.pem", assumed that was trusted, and didn't need to look any further.

--- complete setup ---

Here is the complete ssl configuration used:

    ssl on;
    ssl_certificate /etc/letsencrypt/live/go-oio.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/go-oio.com/privkey.pem; # managed by Certbot

    #ssl_trusted_certificate /etc/letsencrypt/live/go-oio.com/fullchain.pem; 

    ssl_stapling on;
    ssl_stapling_verify on;

    resolver_timeout 10s;

    ssl_session_cache shared:SSL:32m;
    ssl_buffer_size 8k;
    ssl_session_timeout 180m;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;

    add_header Strict-Transport-Security max-age=15768000;

As you can see, ssl_stapling_verify is on

and ssl_trusted_certificate is comment out with a #

Of course I did not forget

sudo service nginx restart

before running the ssl test from a browser on a different network from the VPS:

which reported:

OCSP Must Staple Supported
OCSP stapling Yes

Path #1: Trusted
1 Sent by server go-oio.com
Fingerprint SHA256: 0e2c273d1dc3f9661dfe7739f5550ccc372013ce6c39b620481199db4ab2bf20
Pin SHA256: Yb8lO2XNnya2Raups1RGpfYX0QfcD/DZogANo4ACcn4=
RSA 2048 bits (e 65537) / SHA256withRSA

2 Sent by server Let's Encrypt Authority X3
Fingerprint SHA256: 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA

3 In trust store DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate