Project

General

Profile

Documentation #13523

rgw: document civetweb ssl configuration

Added by Jiang Yu over 8 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
% Done:

0%

Tags:
Backport:
luminous
Reviewed:
Affected Versions:
Pull request ID:

Description

The following is my Configuration file?But using http
ceph.conf
[client.radosgw.gateway]
host = B-80-11
keyring = /etc/ceph/keyring.radosgw.gateway
rgw frontends = "civetweb port=80"
rgw socket path = /tmp/radosgw.sock
log file = /var/log/ceph/radosgw.log

How do I configure civetweb use https?


Related issues

Duplicated by rgw - Documentation #13670: rgw frontends not mentioned in radosgw config-ref Duplicate 11/02/2015
Copied to rgw - Backport #22884: luminous: rgw: document civetweb ssl configuration Resolved

History

#1 Updated by Anonymous over 8 years ago

Jiang,

I've only thus far worked with hammer, so you'll need to confirm this on your firefly installation. However, civetweb by default uses dlopen() to load crypto/ssl libraries. Assuming this code path works on your system (ie. library naming/versioning is not an issue), it should be a matter of correctly specifying 'rgw_frontends'.

Basically, something like: rgw_frontends = civetweb port=443s ssl_certificate=/path/to/your/cert.pem

Note the 's' on the port number is necessary to specify SSL.

Try this out and see how it goes.

-Karol

#2 Updated by Jiang Yu over 8 years ago

Thank you very much,Let me try.
The reason why the configuration civetweb, because apache + fastcgi in our production environment uses two domain names. When using a browser JS call radosgw, there have been cross-border problems. The browser sends the OPTIONS request, leading to radosgw not recognized.
Under normal circumstances are:
1. Browser starting OPTIONS request
2. Cross-domain license server reply
3. The browser sends a GET request
4. Server Reply Data
However, step 2, the server replies 403, cause the browser can not receive cross-domain license, it will not send a GET request.
Is there a better way to handle it?

#3 Updated by Nathan Cutler over 8 years ago

  • Project changed from Ceph to rgw

#4 Updated by Russell Islam over 7 years ago

Any documentation available?

#5 Updated by Yehuda Sadeh over 7 years ago

  • Tracker changed from Bug to Documentation
  • Subject changed from How do I configure civetweb use https to rgw: document civetweb ssl configuration
  • Assignee set to Marcus Watts

#6 Updated by Yehuda Sadeh over 7 years ago

  • Priority changed from Normal to High

#7 Updated by Yehuda Sadeh over 7 years ago

  • Release deleted (firefly)
  • Affected Versions deleted (0.80)

#8 Updated by Russell Islam over 7 years ago

All the steps for configuring multistage rgw are for http only. Could you please give us the steps for https along with SSL configuration. I tried using the following config.

[client.rgw.ceph-us-east-1]
rgw_frontends = civetweb port=443s ssl_certificate=/etc/pki/tls/ca.pem
rgw_zone=ceph-us-east-1

Primary zone is fine but when I try to pull the realm from west region got the following curl error.

adosgw-admin realm pull --url=https://ceph-us-east-1:443 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
request failed: (22) Invalid argument
2016-07-22 14:59:30.532614 7ff59310f9c0 0 curl_easy_perform returned error: Peer's certificate issuer has been marked as not trusted by the user.
I think SSL configuration was not done properly for civentweb based gateway.

Any information would me much appreciated.

FYI:
steps used for SSL
openssl genrsa -out ca.key 2048
openssl req -new -key ca.key -out ca.csr -subj "/C=US/ST=California/L=City/O=Company/OU=Linux/CN=www.company.com"
openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
cp -f ca.crt /etc/pki/tls/certs
cp -f ca.key /etc/pki/tls/private/ca.key
cp -f ca.csr /etc/pki/tls/private/ca.csr
cp ca.crt ca.pem
cat ca.key >> ca.pem
cp ca.pem /etc/pki/tls/

#9 Updated by Marcus Watts almost 7 years ago

Cephs's rados/ssl support has been a bit slower than I would have liked. However, it should be getting better now, and you evidently have found one of the working flavors.

There are 2 things you'll probably want to do with your certificates. (a) you'll want to add "subjectAltName" for entries for all the host names you want your radosgw to be known by. And (b) on the client side you need to make sure the CA is trusted.

For (a) - if using openssl, add: [v3_req] subjectAltName = ${ENV::SAN}, then when running openssl req, prefix with env SAN=DNS:fqdn. Verify your req has "requested extensions: X509v3 Subject Alternative Name:" before signing it,
and that the resulting certificate has "X509v3 Subject Alternative Name:".

For (b) - making the CA trusted depends on the distribution as well as which software (openssl, nss, and java apps will look different places.) For red hat distributions, one of the key commands is "update-ca-trust". For debian based, one equivalent is dpkg-reconfigure ca-certificates. Where you put the ca cert and what else you do is complicated. Putting your ca cert under /etc/pki/tls/certs/ might not be best. Also note firefox has its own ca store.

#10 Updated by Casey Bodley about 6 years ago

https://github.com/ceph/ceph/pull/20058

adds basic documentation for rgw_frontend options

#11 Updated by Nathan Cutler about 6 years ago

  • Status changed from New to Fix Under Review
  • Assignee changed from Marcus Watts to Casey Bodley

#12 Updated by Nathan Cutler about 6 years ago

#13 Updated by Casey Bodley about 6 years ago

  • Backport set to luminous

@Nathan, I'd like to get this documentation backported to luminous, but it won't let me change the `Status` here

also, the backport should probably show '.. versionadded:: Luminous' for Beast (as we're planning to backport any further development), rather than mentioning Mimic

#14 Updated by Casey Bodley about 6 years ago

  • Copied to Backport #22884: luminous: rgw: document civetweb ssl configuration added

#15 Updated by Nathan Cutler about 6 years ago

  • Status changed from Fix Under Review to Pending Backport

#16 Updated by Nathan Cutler about 6 years ago

@Casey: I thought I had added the "Pending Backport" status to the Documentation tracker already. . . should be fixed now. I had to edit the workflows.

#17 Updated by Nathan Cutler about 6 years ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF