Why is this OCSP response reporting a hash using SHA1?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is this OCSP response reporting a hash using SHA1?

Robert Moskowitz
I am using the test responder:

    openssl ocsp -port 2560 -text -rmd sha256\
          -index index.txt \
          -CA certs/ca-chain.cert.pem \
          -rkey private/$ocspurl.key.pem \
          -rsigner certs/$ocspurl.cert.pem \
          -nrequest 1


What is the SHA1 hash report about?  It comes right after the line:
Certificate ID:


openssl ocsp -CAfile certs/ca-chain.cert.pem \
           -url http://127.0.0.1:2560 -resp_text \
           -issuer certs/8021ARintermediate.cert.pem \
           -cert certs/$targetcert.cert.pem

OCSP Response Data:
     OCSP Response Status: successful (0x0)
     Response Type: Basic OCSP Response
     Version: 1 (0x0)
     Responder Id: O = HTT Consulting, OU = Devices
     Produced At: Sep  8 16:11:38 2017 GMT
     Responses:
     Certificate ID:
       Hash Algorithm: sha1
       Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0
       Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0
       Serial Number: 762900CAB55A4762
     Cert Status: revoked
     Revocation Time: Sep  7 06:48:28 2017 GMT
     This Update: Sep  8 16:11:38 2017 GMT

     Response Extensions:
         OCSP Nonce:
             0410DBAEC40AE0C9696C715A8F476383D112
     Signature Algorithm: ecdsa-with-SHA256
          30:46:02:21:00:a7:3e:9f:40:29:21:bc:1b:af:22:41:f7:5d:
          70:d8:3f:db:98:16:7c:62:b4:e9:cf:4c:1e:43:db:fa:07:42:
          f7:02:21:00:f6:05:82:c8:85:ef:dc:17:ec:0f:59:ce:5e:fd:
          36:8f:ac:5a:29:32:17:9d:22:c1:c2:77:e8:f7:7a:0c:ff:af
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             aa:56:78:7a:d5:f7:de:4f
     Signature Algorithm: ecdsa-with-SHA256
         Issuer: C=US, ST=MI, O=HTT Consulting, OU=Devices, CN=802.1AR CA
         Validity
             Not Before: Sep  7 06:40:11 2017 GMT
             Not After : Dec 31 23:59:59 9999 GMT
         Subject: O=HTT Consulting, OU=Devices
         Subject Public Key Info:
             Public Key Algorithm: id-ecPublicKey
                 Public-Key: (256 bit)
                 pub:
                     04:d8:a1:6c:09:c0:13:fc:30:6f:02:1e:a0:d3:cc:
                     02:8c:b0:e1:2a:84:1d:94:ed:2e:92:b8:25:d0:00:
                     3d:a0:1a:43:dc:83:12:13:e0:74:a4:97:b7:4e:ed:
                     26:18:c0:36:38:a1:f8:c0:bb:d8:5c:14:cd:a7:23:
                     f5:71:51:bc:6c
                 ASN1 OID: prime256v1
                 NIST CURVE: P-256
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             X509v3 Subject Key Identifier:
                 57:34:03:80:50:53:9B:EA:2A:06:37:FF:8A:1E:32:72:70:DD:41:9F
             X509v3 Authority Key Identifier:
                 keyid:A3:27:8D:00:B0:53:BF:25:91:93:A4:83:3E:66:9C:45:1D:AD:36:E0

             X509v3 Key Usage: critical
                 Digital Signature
             X509v3 Extended Key Usage: critical
                 OCSP Signing
             X509v3 Subject Alternative Name:
                 DNS:ocsp.htt-consult.com, email:[hidden email]
     Signature Algorithm: ecdsa-with-SHA256
          30:44:02:20:2b:99:ba:72:2a:e5:4c:1b:c1:9c:6a:72:f9:8e:
          8f:5f:97:ec:35:e0:19:f3:7f:58:c4:4b:67:fe:dc:47:68:45:
          02:20:37:07:0a:be:09:bd:20:b5:21:c5:23:80:4a:4d:57:47:
          56:4a:79:cc:6d:e0:57:5e:ef:bc:9b:eb:6d:3a:db:73
-----BEGIN CERTIFICATE-----
MIICMTCCAdigAwIBAgIJAKpWeHrV995PMAoGCCqGSM49BAMCMFoxCzAJBgNVBAYT
AlVTMQswCQYDVQQIDAJNSTEXMBUGA1UECgwOSFRUIENvbnN1bHRpbmcxEDAOBgNV
BAsMB0RldmljZXMxEzARBgNVBAMMCjgwMi4xQVIgQ0EwIBcNMTcwOTA3MDY0MDEx
WhgPOTk5OTEyMzEyMzU5NTlaMCsxFzAVBgNVBAoMDkhUVCBDb25zdWx0aW5nMRAw
DgYDVQQLDAdEZXZpY2VzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2KFsCcAT
/DBvAh6g08wCjLDhKoQdlO0ukrgl0AA9oBpD3IMSE+B0pJe3Tu0mGMA2OKH4wLvY
XBTNpyP1cVG8bKOBszCBsDAJBgNVHRMEAjAAMB0GA1UdDgQWBBRXNAOAUFOb6ioG
N/+KHjJycN1BnzAfBgNVHSMEGDAWgBSjJ40AsFO/JZGTpIM+ZpxFHa024DAOBgNV
HQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwkwOwYDVR0RBDQwMoIU
b2NzcC5odHQtY29uc3VsdC5jb22BGnBvc3RtYXN0ZXJAaHR0LWNvbnN1bHQuY29t
MAoGCCqGSM49BAMCA0cAMEQCICuZunIq5UwbwZxqcvmOj1+X7DXgGfN/WMRLZ/7c
R2hFAiA3Bwq+Cb0gtSHFI4BKTVdHVkp5zG3gV17vvJvrbTrbcw==
-----END CERTIFICATE-----
Response verify OK
certs/Wt1234.cert.pem: revoked
        This Update: Sep  8 16:11:38 2017 GMT
        Revocation Time: Sep  7 06:48:28 2017 GMT


Thank you

Bob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Dr. Stephen Henson
On Fri, Sep 08, 2017, Robert Moskowitz wrote:

> I am using the test responder:
>
>    openssl ocsp -port 2560 -text -rmd sha256\
>          -index index.txt \
>          -CA certs/ca-chain.cert.pem \
>          -rkey private/$ocspurl.key.pem \
>          -rsigner certs/$ocspurl.cert.pem \
>          -nrequest 1
>
>
> What is the SHA1 hash report about?  It comes right after the line:
> Certificate ID:
>
>     Certificate ID:
>       Hash Algorithm: sha1
>       Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0
>       Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0
>       Serial Number: 762900CAB55A4762

It's the hash algorithm used to hash the issuer name and key to identify them.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Robert Moskowitz


On 09/08/2017 10:08 PM, Dr. Stephen Henson wrote:

> On Fri, Sep 08, 2017, Robert Moskowitz wrote:
>
>> I am using the test responder:
>>
>>     openssl ocsp -port 2560 -text -rmd sha256\
>>           -index index.txt \
>>           -CA certs/ca-chain.cert.pem \
>>           -rkey private/$ocspurl.key.pem \
>>           -rsigner certs/$ocspurl.cert.pem \
>>           -nrequest 1
>>
>>
>> What is the SHA1 hash report about?  It comes right after the line:
>> Certificate ID:
>>
>>      Certificate ID:
>>        Hash Algorithm: sha1
>>        Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0
>>        Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0
>>        Serial Number: 762900CAB55A4762
> It's the hash algorithm used to hash the issuer name and key to identify them.

And how do you get it to use sha256?

I would think that the -rmd sha256 in the responder command would that?  
What does it do anyway?  It is listed in the -help:

  -rmd val                Digest Algorithm to use in signature of OCSP
response

but not in the man page.

Ah,  put -sha256 in the CLIENT request.  Seems kind of backward.  Or at
least the server should have some control over the hash used?

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

OpenSSL - User mailing list

   
    Ah,  put -sha256 in the CLIENT request.  Seems kind of backward.  Or at
    least the server should have some control over the hash used?
   

Well, it is the client that is making the request, so therefore the client needs to hash the cert information.

A production-quality OCSP responder might have configuration controls to specify which type of digests it wants to see in the request.  As with most of the OpenSSL command-line interface, it’s not a product.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Robert Moskowitz


On 09/11/2017 12:23 PM, Salz, Rich via openssl-users wrote:
>      
>      Ah,  put -sha256 in the CLIENT request.  Seems kind of backward.  Or at
>      least the server should have some control over the hash used?
>      
>
> Well, it is the client that is making the request, so therefore the client needs to hash the cert information.

Ah, I see.  I was looking at this from the wrong side.

> A production-quality OCSP responder might have configuration controls to specify which type of digests it wants to see in the request.  As with most of the OpenSSL command-line interface, it’s not a product.

Understood.  This is mostly about providing a development/testing
environment.  And if your standard calls out use of OCSP, then you
really should include that in testing.  I am getting ready to focus on
the IETF SIngapore hackathon...

I would actually really like to have a SIMPLE OCSP responder.  But so
far have not found one.  freeIPA has one buried within it, but that is
too disruptive to install unless you buy into freeIPA.

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Dr. Stephen Henson
On Mon, Sep 11, 2017, Robert Moskowitz wrote:

>
> I would actually really like to have a SIMPLE OCSP responder.  But
> so far have not found one.  freeIPA has one buried within it, but
> that is too disruptive to install unless you buy into freeIPA.
>

Well the OpenSSL ocsp respoder isn't much use for that, it only handles one
request at a time, can't handle dynamic updates in the status information
(needs to be restarted), has pretty awful performance (reads status from a
text file which resides in memory) and you can't tell it which interface to
bind to either.

There is a way to deal with some of those issues by running the ocsp utility
from a CGI script in a web server. The script decodes the OCSP request, hands
it to the ocsp utility and sends back the response. The down side is the
performance is worse: the OCSP utility has to parse the text file and read it
into memory on every incoming request.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Robert Moskowitz


On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote:

> On Mon, Sep 11, 2017, Robert Moskowitz wrote:
>
>> I would actually really like to have a SIMPLE OCSP responder.  But
>> so far have not found one.  freeIPA has one buried within it, but
>> that is too disruptive to install unless you buy into freeIPA.
>>
> Well the OpenSSL ocsp respoder isn't much use for that, it only handles one
> request at a time, can't handle dynamic updates in the status information
> (needs to be restarted), has pretty awful performance (reads status from a
> text file which resides in memory) and you can't tell it which interface to
> bind to either.
>
> There is a way to deal with some of those issues by running the ocsp utility
> from a CGI script in a web server. The script decodes the OCSP request, hands
> it to the ocsp utility and sends back the response. The down side is the
> performance is worse: the OCSP utility has to parse the text file and read it
> into memory on every incoming request.

Yeah, I thought of the cgi (or php) approach and kind of cringed. That
is why I am still googling for OCSP responders.  Rather depressing how
little is out there.

Also nice would be index.txt in SQL.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Robert Moskowitz


On 09/12/2017 09:38 AM, Robert Moskowitz wrote:

>
>
> On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote:
>> On Mon, Sep 11, 2017, Robert Moskowitz wrote:
>>
>>> I would actually really like to have a SIMPLE OCSP responder.  But
>>> so far have not found one.  freeIPA has one buried within it, but
>>> that is too disruptive to install unless you buy into freeIPA.
>>>
>> Well the OpenSSL ocsp respoder isn't much use for that, it only
>> handles one
>> request at a time, can't handle dynamic updates in the status
>> information
>> (needs to be restarted), has pretty awful performance (reads status
>> from a
>> text file which resides in memory) and you can't tell it which
>> interface to
>> bind to either.
>>
>> There is a way to deal with some of those issues by running the ocsp
>> utility
>> from a CGI script in a web server. The script decodes the OCSP
>> request, hands
>> it to the ocsp utility and sends back the response. The down side is the
>> performance is worse: the OCSP utility has to parse the text file and
>> read it
>> into memory on every incoming request.
>
> Yeah, I thought of the cgi (or php) approach and kind of cringed. That
> is why I am still googling for OCSP responders.  Rather depressing how
> little is out there.
I see ocspd available in Fedora.  I will have to do a bit of
reading....  Perhaps part of OpenCA,,,

Sometimes start in the 'obvious' starting point.  Like your own OS repo...


>
> Also nice would be index.txt in SQL.
>
> Bob
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Why is this OCSP response reporting a hash using SHA1?

Jakob Bohm-7
On 12/09/2017 15:56, Robert Moskowitz wrote:

>
>
> On 09/12/2017 09:38 AM, Robert Moskowitz wrote:
>>
>>
>> On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote:
>>> On Mon, Sep 11, 2017, Robert Moskowitz wrote:
>>>
>>>> I would actually really like to have a SIMPLE OCSP responder.  But
>>>> so far have not found one.  freeIPA has one buried within it, but
>>>> that is too disruptive to install unless you buy into freeIPA.
>>>>
>>> Well the OpenSSL ocsp respoder isn't much use for that, it only
>>> handles one
>>> request at a time, can't handle dynamic updates in the status
>>> information
>>> (needs to be restarted), has pretty awful performance (reads status
>>> from a
>>> text file which resides in memory) and you can't tell it which
>>> interface to
>>> bind to either.
>>>
>>> There is a way to deal with some of those issues by running the ocsp
>>> utility
>>> from a CGI script in a web server. The script decodes the OCSP
>>> request, hands
>>> it to the ocsp utility and sends back the response. The down side is
>>> the
>>> performance is worse: the OCSP utility has to parse the text file
>>> and read it
>>> into memory on every incoming request.
>>
>> Yeah, I thought of the cgi (or php) approach and kind of cringed.
>> That is why I am still googling for OCSP responders. Rather
>> depressing how little is out there.
> I see ocspd available in Fedora.  I will have to do a bit of
> reading....  Perhaps part of OpenCA,,,
>
Yes it's part of OpenCA, not sure of the OpenCA project status though.

Another standalone ocsp responder, which unfortunately seems to require
a complete Java environment and a Java driver to treat the cert list as
a "database" is the one from EJBCA.

EJBCA seems to be very actively maintained and some professionals
consider it the best CA implementation suite.

> Sometimes start in the 'obvious' starting point.  Like your own OS
> repo...
>
>
>>
>> Also nice would be index.txt in SQL.
>>
>> Bob
>>
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users