3

Okay, so I have a multi-layered ca system that looks like this:

-ROOT_CA

----intermediate_CA

--------intermediate_CA2

------------client certs...

I have an OCSP responder set up on intermediate_CA2 that is started like so:

$ openssl ocsp -index intermedia_ca_2_index.txt -CA ca_crt_chain.crt -rsigner intermedia_ca_2.crt     -rkey intermedia_ca_2.key -port xxxx -text

On the client side, I make an ocsp request like so:

$ openssl ocsp -issuer ca_crt_chain.crt -CAfile ca_crt_chain.crt -cert client.crt -text -host localhost:xxxx -verify_other... -trust_other

Note that client.crt is just the client cert, not the entire chain, though I have tried both ways and neither work. It always returns

Response verify OK
client.crt: unknown

If I change -cert client.crt to -serial 0xXXXXXXXXX (Obviously passing in a valid serial that cooresponds to client.crt) then everything works with:

Response verify OK
0xXXXXXXXXX: good 

Oddly enough, if I examine the request in the first example, it is, indeed, sending the correct serial.

I can't for the life of me figure this out. Any ideas?

jonbonazza
  • 926
  • 2
  • 10
  • 16

2 Answers2

3

So the solution is that apparently openssl ocsp doesn't like chain files. So my server call looks like this now:

$ openssl ocsp -index intermedia_ca_2_index.txt -CA intermediate_ca_2.crt -rsigner intermedia_ca_2.crt -rkey intermedia_ca_2.key -port xxxx -text

Note that it would be more preferable to have an entirely seperate key pair for signing, but w/e.

The client connection would then look like so:

$ openssl ocsp -issuer intermediate_ca_2.crt -CApath /path/to/trust/store -cert client.crt -text -url http://localhost:xxxx
jonbonazza
  • 926
  • 2
  • 10
  • 16
0

This has been fixed OpenSSL 1.1.1a (see this commit).

This can be verified with the commands listed in my issue.

darkdragon
  • 392
  • 5
  • 13