Skip to main content

Problems with OCSP stapling

Spork Schivago
So I generate my SSL certificate using Let's Encrypt binary program. My certificate has the OCSP Must Staple extension added and a valid OCSP response is stapled to the certificate that the server offers during TLS. When I look at the SSL virtual host entry in the httpd.conf though, I see SSLUseStapling off. In the ssl_vhost template, I see:
[% IF supported.stapling && !has_ocsp(vhost.sslcertificatefile) -%] SSLUseStapling off [% END -%]
So, my certificate I believe is setup properly, but for some reason, cPanel is thinking it's not enabled. Is there something in WHM that I have to setup or configure to get this working? Qualy's SSL Lab test shows:
This server certificate supports OCSP must staple but OCSP response is not stapled.
From what I've read, I believe this means it's just turned off in Apache's configuration file, and if I were to change the SSLUseStapling off to on, it should work.... Any suggestions?

Comments

9 comments

Date Votes
  • Infopro
    A similar thread here might be of some use: LetsEncrypt OCSP stapling issue
    0
  • Spork Schivago
    Thank you for the help InfoPro, but after reading the thread you pointed me to, I don't think this is the issue. I check my certificate details in the browser and I see the certificate is valid from 6/19/2017 to 9/17/2017. I've even rebuilt the httpd.conf file, but for whatever reason, when the template is ran, it's still detecting no stapling and turning it off in the SSL virtual host section. I've verified the CA Bundle in /var/cpanel/ssl/installed/cabundles matches what's in /etc/letsencrypt/www.mydomain.com/chain.pem I see the the: SSLCACertificateFile /var/cpanel/ssl/installed/cabundles/Let_s_Encrypt_d5a69d0f2effae8513e08eaced2ccf28_1615999246.cabundle directive in httpd.conf. I verified all the certs in the /etc/letsencrypt/www.mydomain.com/ directory have the proper time stamp. WHM >> SSL / TLS >> Manage SSL Hosts shows the certificates were properly installed. I see four domains listed. Two for the IPv4 address and two for the IPv6 address (mydomain.com and www.mydomain.com). They both show an expiration date of 9/17/17. I see for the IPv6 address, SNI is required, for the IPv4 address, SNI is not required. The IPv6 address shows it's dedicated and the primary website is not on that address, and for the IPv4 address, it shows it's a shared IP address and the primary website is on that address. I don't know if that's all proper or not, so I figured I'd mention it. **EDIT: I just rebuilt the httpd.conf file again, but instead of using /scripts/rebuildhttpdconf, I did it through WHM. I noticed now the SSLUseStapling off line is gone from the :443 virtualhost entry. I'm running the Qualy's SSL Lab test again now to see if it's working. I use the WHM API2 calls to install the SSL certificates. Whenever Let's Encrypt generates a new certificate for my site, should I call /scripts/rebuildhttpdconf ? Maybe I didn't run /scripts/rebuildhttpdconf like I remember....
    0
  • vlee
    This is what I have in Home "Service Configuration "Apache Configuration "Include Editor Pre VirtualHost Include
    # Enable SSLUseStapling SSLUseStapling on SSLStaplingCache shmcb:/tmp/stapling_cache(128000) SSLHonorCipherOrder On SSLCompression off
    I hope this helps
    0
  • Spork Schivago
    This is what I have in Home "Service Configuration "Apache Configuration "Include Editor Pre VirtualHost Include
    # Enable SSLUseStapling SSLUseStapling on SSLStaplingCache shmcb:/tmp/stapling_cache(128000) SSLHonorCipherOrder On SSLCompression off
    I hope this helps

    You shouldn't have to set the SSLUseStapling or SSLStaplingCache directive in your Pre VirtualHost Include, for what it's worth. The cPanel Apache ssl_vhost.default template will automatically add those two directives if it detects OSCP stapling in the certificate. At least that's what I can gather by looking at the template file. Once I rebuilt the httpd.conf file, it worked as expected. Also, I don't specifically turn off SSLCompression, but the SSL labs test shows it's turned off, so that might be another one you could possibly remove. Thanks!
    0
  • vlee
    You shouldn't have to set the SSLUseStapling or SSLStaplingCache directive in your Pre VirtualHost Include, for what it's worth. The cPanel Apache ssl_vhost.default template will automatically add those two directives if it detects OSCP stapling in the certificate. At least that's what I can gather by looking at the template file. Once I rebuilt the httpd.conf file, it worked as expected. Also, I don't specifically turn off SSLCompression, but the SSL labs test shows it's turned off, so that might be another one you could possibly remove. Thanks!

    Thank you for this because the old way I had to do this older versions and now I have 3 less directives to worry about.
    0
  • Spork Schivago
    Thank you for this because the old way I had to do this older versions and now I have 3 less directives to worry about.

    Yeah, I thought you might like that. Unfortunately, I feel I still need to use modified templates. There's things I try setting up that I can't seem to find away to properly setup by using the includes. I'd love to use the includes. One of them is with the HSTS I think. With the includes, it sends the header over unencrypted channels (http), but the STS draft standard says the Strict-Transport-Security header must not be sent over an unencrypted channel. The only way I can figure out how to do this is to use the templates. I do see in the /etc/apache2/conf/httpd.conf file, for the SSL virtualhost entries,
    # To customize this VirtualHost use an include file at the following location # Include "/etc/apache2/conf.d/userdata/ssl/2_4/username/example.com/*.conf"
    So I might be able to put my HSTS and other header stuff in there. But I see how the Include directive there is commented out. I'm wondering if a conf file exists in that directory, if it'll get uncommented. If not, I don't see where it gets loaded. That's the only occurrence of that specific directive. I'd love to move away from using the templates....
    0
  • vlee
    This is what I have in Home "Service Configuration "Apache Configuration "Include Editor for Strict-Transport-Security header Pre VirtualHost Include
    # Enable HTTP Strict Transport Security Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    I am in for a better way of doing this above as well as these below
    # SSLHonorCipherOrder SSLHonorCipherOrder On

    # Enable HTTP Secure Cookie Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
    0
  • Spork Schivago
    This is what I have in Home "Service Configuration "Apache Configuration "Include Editor for Strict-Transport-Security header Pre VirtualHost Include
    # Enable HTTP Strict Transport Security Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    ...

    But by putting this header in the Pre VirtualHost include, the header is sent when someone visits on port 80 or port 443, isn't it? And although HSTS works, this is in violation of the draft I believe. The HSTS header should only be sent over secure channels. Although this will give you a good report on something like Qualy's SSL lab test, if you use an auditing service, like scanmyserver.com or something, you'll see you're failing a security test:
    2. Non-compliant Strict Transport Security (STS) (Low) Port: https (443/tcp) Summary: The remote web server implements Strict Transport Security. However, it does not respect all the requirements of the STS draft standard. The Strict-Transport-Security header must not be sent over an unencrypted channel. More information: http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html Test ID: 12059
    I don't think it's a big deal or anything, but personally, I try to follow the draft. I'm going to look at that secure cookie thing. This is what I have under the []:443> entry:
    # Enable HTTP Strict Transport Security Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" # Prevent Clickjacking attacks. # -- SAMEORIGIN: This setting will allow page to be displayed # in frame on the same origin as the page itself. Header always set X-Frame-Options SAMEORIGIN # Prevent "MIME" based attacks. # -- This header prevents IE and Chrome from MIME-sniffing # a response away from the declared content-type as the type # header instructs the browser not to override the response # With the nosniff option, if the server says the content # type is text/html, the browser will rent it as text/html. Header always set X-Content-Type-Options nosniff
    0
  • Spork Schivago
    I figured out how to set that various options without using the /var/cpanel/templates/apache2_4/ssl_vhost.local template file. I did this:
    mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4//example.com/ nano -w /etc/apache2/conf.d/userdata/ssl/2_4//example.com/secure_https.conf # Enable HTTP Strict Transport Security Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" # Prevent Clickjacking attacks. # -- SAMEORIGIN: This setting will allow page to be displayed # in frame on the same origin as the page itself. Header always set X-Frame-Options SAMEORIGIN # Prevent "MIME" based attacks. # -- This header prevents IE and Chrome from MIME-sniffing # a response away from the declared content-type as the type # header instructs the browser not to override the response # With the nosniff option, if the server says the content # type is text/html, the browser will rent it as text/html. Header always set X-Content-Type-Options nosniff
    Than I saved the file, rebuilt the httpd.conf file and restarted Apache:
    /scripts/rebuildhttpdconf systemctl restart httpd
    I checked to verify the headers were working properly, for just https connections and not http connections:
    [root@franklin conf.d]# curl -I http://example.com HTTP/1.1 301 Moved Permanently Date: Mon, 26 Jun 2017 18:32:00 GMT Server: Apache Location: https://example.com/ Content-Type: text/html; charset=iso-8859-1 [root@franklin conf.d]# curl -I http://www.example.com HTTP/1.1 301 Moved Permanently Date: Mon, 26 Jun 2017 18:32:04 GMT Server: Apache Location: https://www.example.com/ Content-Type: text/html; charset=iso-8859-1 [root@franklin conf.d]# curl -I https://example.com HTTP/1.1 200 OK Date: Mon, 26 Jun 2017 18:33:10 GMT Server: Apache Strict-Transport-Security: max-age=63072000; includeSubdomains; preload X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Cache-Control: max-age=0, no-cache, no-store, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Expires: Wed, 11 Jan 1984 05:00:00 GMT Content-Type: text/html; charset=UTF-8 [root@franklin conf.d]# curl -I https://www.example.com HTTP/1.1 200 OK Date: Mon, 26 Jun 2017 18:33:14 GMT Server: Apache Strict-Transport-Security: max-age=63072000; includeSubdomains; preload X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Cache-Control: max-age=0, no-cache, no-store, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Expires: Wed, 11 Jan 1984 05:00:00 GMT Content-Type: text/html; charset=UTF-8
    That did away with needing to have the HSTS stuff in the ssl_vhost.local template. I still need to use the templates though, for now, because I have subdomains setup and right now, cPanel creates www ServerAliases for the subdomains. For example, there's ServerAlias www.cpanel.example.com ServerAlias www.whm.example.com These shouldn't be there and I've submitted a feature request for cPanel to remove them (or at least give us an option to enable / disable them). I then went and created a Pre-Virtualhost Include file using WHM to tell Apache to order the cipher list order. Thanks!!!!
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post