Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1515764 - OCSP response letsencrypt permission to key denied
Summary: OCSP response letsencrypt permission to key denied
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-21 10:48 UTC by d.vicesss
Modified: 2017-12-13 15:47 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 15:35:45 UTC


Attachments (Terms of Use)

Description d.vicesss 2017-11-21 10:48:45 UTC
Description of problem:

Using: nginx 1.12.1 with this configuration:

    ssl_stapling on;
    ssl_stapling_verify on;
    
    ssl_trusted_certificate /etc/letsencrypt/live/[domain]/chain.pem;
    resolver valid=86400;
    resolver_timeout 10;

In my `nginx.error` log I get the following message when I access my website:

2017/11/21 11:25:32 [crit] 29221#0: connect() to [ip]:80 failed (13:Permission denied) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: [ip]:80, certificate: "/etc/letsencrypt/live/[domain]/fullchain.pem"

When I disable SELinux with `sudo setenforce 0`, I do not get the error when loading the website. This makes me believe it is a problem with the selinux policy.

Software versions:

- selinux-policy-3.13.1-283.16.fc27
- nginx 1.12.1
- certbot (letsencrypt) 0.19.0

This is 100% reproducible for me.

This does not make the website not load, it just throws the error while still loading the website.

I hope it's not a duplicate, but I could not find it.

Comment 1 Lukas Vrabec 2017-11-21 14:03:11 UTC
Could you reproduce the issue and attach output of: 

# ausearch -m AVC -ts today 


Thanks,
Lukas.

Comment 2 d.vicesss 2017-11-21 19:26:41 UTC
This is the output:

type=AVC msg=audit(1511292345.762:56370): avc:  denied  { name_connect } for  pid=29221 comm="nginx" dest=80 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0

Comment 3 Lukas Vrabec 2017-12-12 15:35:45 UTC
This is the security improvement from F27. If you to allow this rule use following boolean: 
# semanage boolean -m httpd_graceful_shutdown --on

Thanks,
Lukas.

Comment 4 d.vicesss 2017-12-13 15:47:26 UTC
That takes away the error. Thank you for your time and solution. I wasn't aware of this change in F27.


Note You need to log in before you can comment on or make changes to this bug.