Ceph » rgw

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

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?

Any documentation available?

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/

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.

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

adds basic documentation for rgw_frontend options

@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.