Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


WoSign OCSP stapling with nginx
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

WoSign OCSP stapling with nginx

salakissalakis Member

Hi,

following the recommendation on ohling.org I wanted to set up OCSP stapling for my website running nginx with the free WoSign cert.

Using the guide on DigitalOcean I already fail with converting the root CA from DER to PEM...

Is there any fool-proof guide for this or are there any specific things to take care of when doing this with WoSign certs?

Thanks!

Comments

  • MuZoMuZo Member

    From what I understand, if you are using the certificate in the "for nginx" archive (which contains your certificate, the intermediate CA and the root CA) you can simply configure nginx this way so that it will automatically do the queries to the OCSP "server-side when needed":

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    

    Instead of querying the OCSP server-side you can get the result from their certificates saved locally:

    # Source: http://habrahabr.ru/post/254231/
    
    cd /path/to/your/ssl/
    wget -O - https://www.startssl.com/certs/ca.pem | tee -a ca-certs.pem> / dev / null 
    wget -O - https://www.startssl.com/certs/sub.class1.server.ca.pem | tee -a ca-certs.pem> / dev / null 
    wget -O - http://aia.startssl.com/certs/ca.crt | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem> / dev / null 
    wget -O - http://aia1.wosign.com/ca1g2-server1-free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem> / dev / null 
    wget -O - http://aia6.wosign.com/ca6.server1.free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem> / dev / null 
    

    add this line in nginx to the previous configuration:

    ssl_trusted_certificate  "/path/to/your/ssl/ca-certs.pem" ;
    

    But from what I've read you have to keep that ca-certs.pem file updated and I'm not sure if nginx will take care of that or you have to it in a cron job.

    Source:
    http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling

    For the OCSP stapling to work, the certificate of the server certificate issuer should be known. If the ssl_certificate file does not contain intermediate certificates, the certificate of the server certificate issuer should be present in the ssl_trusted_certificate file.

    When set, the stapled OCSP response will be taken from the specified file instead of querying the OCSP responder specified in the server certificate.

    Thanked by 1salakis
  • @MuZo said:

    Thanks, this is just what I was looking for!

  • I've been getting BAD GATEWAY for more than 10 hours from Wosign when querying their revocation server at http://ocsp6.wosign.com/ca6/server1/free
    Anyone else seeing this problem? I think those OCSP certs are only valid for 48h or so. I don't know what happens if a browser can't verify the revocation state of a certificate but it probably won't load the site.

  • I've been getting "Code=404,Reason=Not Found", for a while too - does anyone have any other urls that I should be querying against?

    http://ocsp6.wosign.com/ca6/server1/free is the one in my cert also.

    Thanks

    pechspilz said: I've been getting BAD GATEWAY for more than 10 hours from Wosign when querying their revocation server at http://ocsp6.wosign.com/ca6/server1/free Anyone else seeing this problem? I think those OCSP certs are only valid for 48h or so. I don't know what happens if a browser can't verify the revocation state of a certificate but it probably won't load the site.

  • rm_rm_ IPv6 Advocate, Veteran
    edited August 2015

    pechspilz said: I've been getting BAD GATEWAY for more than 10 hours from Wosign when querying their revocation server at http://ocsp6.wosign.com/ca6/server1/free Anyone else seeing this problem? I think those OCSP certs are only valid for 48h or so. I don't know what happens if a browser can't verify the revocation state of a certificate but it probably won't load the site.

    SUCH CONCERN. Relax, nobody checks these, and if they do, inability to check is not a fatal error (a successful check and the cert in the revoked list may be a different story).

    catatonic said: I've been getting "Code=404,Reason=Not Found", for a while too - does anyone have any other urls that I should be querying against?

    http://ocsp6.wosign.com/ca6/server1/free is the one in my cert also.

    I don't know where did you get this URL, mine are nothing even close.

    Also in general I am of the opinion that this "OCSP stapling" is for OCD types with too much time on their hands, e.g. my preferred Lighttpd doesn't even support this at all, and I am not bothered in the slightest. Everything just works without it, and I did not have any kind of slowdown due to SSL, ever.

  • OCSP lets you know if your connection has been intercepted,
    e.g. my workplace has transparent SSL web filtering.
    With stapling I get an alert to let me know my connection is not encrypted end-to-end.
    With it disabled I get no warning, even though if I manually check the SSL certificate at work it is signed by our work CA rather than the CA I purchased the certificate from.

  • rm_rm_ IPv6 Advocate, Veteran

    bohdans said: certificate at work it is signed by our work CA

    If that is an issue for you, remove your "work CA" from the list of trusted CAs in your browser. If you are not allowed to, change to a better workplace, one where employer respects the privacy of employees. Or you know, just don't visit non-work-related sites, maybe. OCSP has nothing to do with this, while it might somehow warn you as a side effect, that's not its intended purpose at all.

  • ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate "/path/to/for_apache/root_bundle.crt";

    Use the root bundle from the "for apache" zip file.

  • pechspilzpechspilz Member
    edited September 2015

    Just a heads up: Wosign blocks certain IP ranges from accessing their authoritative name servers (i.e. ns8.360wzb.com). This is from an OVH IP range (some src IP work, some don't):

    dig +trace ocsp6.wosign.com

    ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> +trace ocsp6.wosign.com
    ;; global options: +cmd
    .           121753  IN  NS  j.root-servers.net.
    .           121753  IN  NS  i.root-servers.net.
    .           121753  IN  NS  m.root-servers.net.
    .           121753  IN  NS  a.root-servers.net.
    .           121753  IN  NS  f.root-servers.net.
    .           121753  IN  NS  g.root-servers.net.
    .           121753  IN  NS  h.root-servers.net.
    .           121753  IN  NS  k.root-servers.net.
    .           121753  IN  NS  e.root-servers.net.
    .           121753  IN  NS  l.root-servers.net.
    .           121753  IN  NS  d.root-servers.net.
    .           121753  IN  NS  b.root-servers.net.
    .           121753  IN  NS  c.root-servers.net.
    .           121814  IN  RRSIG   NS 8 0 518400 20150916170000 20150906160000 1518 . FzEm3F3mtqToSbECichDjHqhfIwoRWCrxq1KAbyzUejYc3lbdGlK/B8u /NWHcXLAhrZSWoZhoROl88v1yb09Ywv81GiY104FrinlYRyMyf2zDsLX QGl1J4ZbDINIjRJJ3V0F4icv87hd/GqQeH70aNpQUq1G0un0QbG6fFgE HcI=
    ;; Received 397 bytes from 192.168.0.1#53(192.168.0.1) in 96 ms
    
    com.            172800  IN  NS  m.gtld-servers.net.
    com.            172800  IN  NS  l.gtld-servers.net.
    com.            172800  IN  NS  k.gtld-servers.net.
    com.            172800  IN  NS  j.gtld-servers.net.
    com.            172800  IN  NS  i.gtld-servers.net.
    com.            172800  IN  NS  h.gtld-servers.net.
    com.            172800  IN  NS  g.gtld-servers.net.
    com.            172800  IN  NS  f.gtld-servers.net.
    com.            172800  IN  NS  e.gtld-servers.net.
    com.            172800  IN  NS  d.gtld-servers.net.
    com.            172800  IN  NS  c.gtld-servers.net.
    com.            172800  IN  NS  b.gtld-servers.net.
    com.            172800  IN  NS  a.gtld-servers.net.
    com.            86400   IN  DS  30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
    com.            86400   IN  RRSIG   DS 8 1 86400 20150921050000 20150911040000 1518 . BF33r0rrYVfJvYYYCBD0stzm5pDjCBxNIQeGHyduK4Xku56XLs4MRfXc 44HpmzuWvBU4IOKRVXbjh236Eh3rbARbxYIqHx5sKFKI6KVZg0d6K8+7 xTbBCJkpaUAXxoE9lz2mOFEdON/cSxAQyKyT+A/ZLPkZw8QpnaQgn2Nw qYM=
    ;; Received 740 bytes from 198.41.0.4#53(a.root-servers.net) in 956 ms
    
    wosign.com.     172800  IN  NS  ns8.360wzb.com.
    wosign.com.     172800  IN  NS  ns5.360wzb.com.
    wosign.com.     172800  IN  NS  ns6.360wzb.com.
    wosign.com.     172800  IN  NS  ns7.360wzb.com.
    CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
    CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20150915212106 20150908201106 35864 com. PSL/fLCxFV7fdwY4LWjH/vcj7S7legHC05t1lEnb2sKGmXrUqoe3RZVg 9iWUm6aWxwCuEBre8s/fJzyDfYImR2fE6YB5p+GCouWkkSaxZKjNGLDa W01HoGoHOAnS1BOF6DdwODGgVuPGtx3KtB1AIKjQI2VXhOcaIAmE16hs OZQ=
    D0PUNRJA2JN3FURS6ADOO0JKIMK3EDML.com. 86400 IN NSEC3 1 1 0 - D0PV7REMOGVR06OG3UP83ACE47FI394G NS DS RRSIG
    D0PUNRJA2JN3FURS6ADOO0JKIMK3EDML.com. 86400 IN RRSIG NSEC3 8 2 86400 20150915045002 20150908034002 35864 com. SOK0LTeR4EPxQ3nvNzq/64OB8oLwouoeEuCsWmOfuTwcnPLrTADhJAPH 842PfaqpQ0Z4IPuO5bjPbREETvHgs2bk0Wd31pPErAT+B5CdEr6O012F rcgd+HFekay2beG8hdNnCaDZQQ6/zMiqlBANv814iDJk3Ff6uVy7/sMv ziY=
    dig: couldn't get address for 'ns8.360wzb.com': no more
Sign In or Register to comment.