<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 01.01.2019 18:24, ѽ҉ᶬḳ℠ wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:b898d7da-ac48-e39f-e51e-d6f1f40d1373@gmx.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <br>
      <div class="moz-cite-prefix">On 01.01.2019 18:04, A. Schulze
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:1e3d3bb0-ea6b-d6c3-7d4a-c6791b384cd2@andreasschulze.de">
        <pre class="moz-quote-pre" wrap="">Am 01.01.19 um 17:10 schrieb ѽ҉ᶬḳ℠:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Hi,

would appreciate to get this (weird)  error sorted/resolved. Having looked up public sources I could not find a remedy and thus placing my hope on this list.

ssl_stapling_file foo.bar.der;
ssl_stapling  on;

nginx -t then produces:

[emerg] 24249#24249: d2i_OCSP_RESPONSE_bio("/srv/ca/certs/ocsp_to_lan_3.cert.der") failed (SSL: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:Field=responseStatus, Type=OCSP_RESPONSE)

WIth:

 # ssl_stapling  on;

there is no such error?!

openssl x509 -noout -text -inform der -in foo.bar.der prints the certificate just fine. Having switched between utf8 and ascii did not make a difference either, same outcome.

openssl asn1parse -inform DER -in foo.bar.der is also printing the values just fine.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">Hello & happy new year!

you did not mention, how you generate "foo.bar.der".


nginx stapling support may work in two operational modes:

1. only "ssl_stapling on" and no "ssl_stapling_file" given.
-> upon the first request nginx will fetch OCSP sapling data from CA's OCSP-Server and send this information as part of the second any any following requests</pre>
      </blockquote>
      <br>
      The modes are clear to me, and I am looking to deploy -><br>
      <br>
      <blockquote type="cite"
        cite="mid:1e3d3bb0-ea6b-d6c3-7d4a-c6791b384cd2@andreasschulze.de">
        <pre class="moz-quote-pre" wrap="">2. "ssl_stapling on" and "ssl_stapling_file" given.
-> you have to manually provide OCSP data. nginx will server any request including these OCSP data.

The file you reference as "ssl_stapling_file" could be generated by this command:

$ openssl ocsp -no_nonce -respout "${OCSP_STAPLING_FILE}" -CAfile "${CA_CHAIN}" -issuer "${ISSUER}" -cert "${CERT}" -url "${OCSP_URI}"
$ kill -HUP $( cat /path/to/nginx.pid )

that has to be done again after some days.

Andreas</pre>
      </blockquote>
      <br>
      I generate the file the way I would trust is common
      standard/practice (?)<br>
      <ol>
        <li>openssl genpkey -algorithm EC -pkeyopt
          ec_paramgen_curve:P-384 -out foo.bar.key.pem -aes-256-cbc</li>
        <li>openssl req -config foo.bar.cnf -key foo.bar.key.pem -new
          -out foo.bar.csr.pem</li>
        <li>openssl ca -config foobar.ca.cnf -extensions v3_foo-bar
          -days 365 -notext -in foo.bar.csr.pem -out foo.bar.cert.pem</li>
        <li>openssl x509 -outform DER -in foo.bar.cert.pem -out
          foo.bar.cert.der</li>
      </ol>
      <p>It generates a valid cert and openssl has no encoding issues.
        What is difference and why this should not work? And why has the
        other command to be done again after some days?<br>
      </p>
      <br>
    </blockquote>
    <br>
    From a look at
    <a class="moz-txt-link-freetext" href="https://www.openssl.org/docs/man1.1.1/man1/openssl-ocsp.html">https://www.openssl.org/docs/man1.1.1/man1/openssl-ocsp.html</a> it does
    not appear to be the way to generate the ocsp certificate,
    notwithstanding that it would require nginx to respond to an oscp
    request and which does not work in the first place do to the
    encoding issue.<br>
    <br>
    It seems to be an issue somehow with nginx parsing/decoding the ocsp
    certificate. Curiously it happens only there and other certificates
    are not affected.<br>
    <br>
  </body>
</html>