-
Notifications
You must be signed in to change notification settings - Fork 9
ssl endpoint
SSL はエンドツーエンド間の全てのウェブリクエストの暗号化を総合的に行なってくれる暗号化プロトコルです。 極秘データを扱うアプリケーションのデータは、SSL を使って情報が全て安全に送信されることを保証するべきでしょう。
例えば www.example.com のようなカスタムドメインの SSL を有効にするには、SSL Endpoint アドオン(SSL Endpointを使います。これは有料アドオンサービスです。サービスを利用する場合はこれを覚えておいて下さい。
SSL の確認は独特な性質のため、アプリケーションから SSL を使えるようにするにはサードパーティーとのやりとりを含んだ複数のステップが必要になります。以下に必要なことを示します:
- SSL プロバイダーから SSL 証明書を購入する。
- Heroku から SSL エンドポイントを使えるようにする。
- 証明書を Heroku にアップロードする。
- 新しい SSL エンドポイント URL を参照するよう DNS の設定を更新する。
callout Staging, and other non-production, apps can use a free [self-signed SSL certificate] (https://devcenter.heroku.com/articles/ssl-certificate-self) instead of purchasing one.
SSL 証明書の購入には、ベンダーによってコストやプロセスにバリエーションがあります。 DNSimple は証明書の購入手順が最も簡単なため、利用を強く推奨します。もしあなたが DNSimple を使えない場合は、purchasing an SSL cert with DNSimple を見て勉強して下さい。
別の SSL プロバイダーを使う場合は、いくつかもしくは全てのステップを要求してくるはずです。
（訳者注：証明書の取得方法については、面倒なので今のところ訳すのはスキップします。）
Before requesting an SSL cert, you need to generate a private key in your local environment using the openssl tool. If you aren't able to execute the openssl command from the terminal you may need to install it.
| If you have... | Install with... |
|---|---|
| Mac OS X |
Homebrew: brew install openssl
|
| Windows | Windows complete package .exe installer |
| Ubuntu Linux | apt-get install openssl |
Use openssl to generate a new private key.
callout When prompted, enter an easy password value as it will only be used when generating the CSR and not by your app at runtime.
$ openssl genrsa -des3 -out server.pass.key 2048
...
Enter pass phrase for server.pass.key:
Verifying - Enter pass phrase for server.pass.key:
The private key needs to be stripped of its password so it can be loaded without manually entering the password.
$ openssl rsa -in server.pass.key -out server.key
You now have a server.key private key file in your current working directory.
CSR(Certificate Signing Request) の生成
A CSR is a certificate signing request and is also required when purchasing an SSL cert. Using the private key from the previous step, generate the CSR. This will require you to enter identifying information about your organization and domain.
Though most fields are self-explanatory, pay close attention to the following:
| Field | Description |
|---|---|
| Country Name | The two letter code, in ISO 3166-1 format, of the country in which your organization is based. |
| Common Name | This is the fully qualified domain name that you wish to secure.
|
warning The
Common Namefield must match the secure domain. You cannot purchase a certificate for the root domain, e.g.,example.com, and expect to securewww.example.com. The inverse is also true. Additionally, SSL Endpoint only supports one certificate per app. Please keep this in mind for multi-domain applications and specify aCommon Domainthat matches all required domains.
Generate the CSR:
$ openssl req -nodes -new -key server.key -out server.csr
...
Country Name (2 letter code) [AU]:US
Common Name (eg, YOUR name) []:www.example.com
...
The result of this operation will be a server.csr file in your local directory (alongside the server.key private key file from the previous step).
Next, begin the process of creating a new SSL certificate with your chosen certificate provider. This will vary depending on your provider, but at some point you will need to upload the CSR generated in the previous step.
You may also be asked for what web server to create the certificate. If so, select Nginx as the web server for use on Heroku. If Nginx is not an option, Apache 2.x will also suffice.
If you want to secure more than one subdomain you will need to purchase a wildcard certificate from your provider. While these certificates are typically more expensive, they allow you to serve requests for all subdomains of *.example.com over SSL.
On completion of the SSL certificate purchase process you should have several files including:
- The SSL certificate for the domain specified in your CSR, downloaded from your certificate provider. This file will have either a
.pemor.crtextension. - The private key you generated in the first step,
server.key.
If your certificate provider requires, you may also have an intermediate certificate or certificate bundle. This file usually has a .pem extension.
一度 SSL 証明書ファイル、秘密鍵と中間CA証明書が揃っていれば、アプリケーションの SSL エンドポイントを設定する準備はできています。最初にエンドポイントを設定します。
$ heroku addons:add ssl:endpoint
Adding ssl:endpoint on example... done, v1 ($20/mo)
付記: 既に証明書を追加している場合、代わりに
certs:updatecommand を使います。
次に証明書、中間CA証明書、あなたのエンドポイントへのプライベートキーを certs:add で追加します。
$ heroku certs:add server.crt bundle.pem server.key
Adding SSL Endpoint to example... done
example now served by tokyo-2121.herokussl.com.
Certificate details:
Expires At: 2012-10-31 21:53:18 GMT
Issuer: C=US; ST=CA; L=SF; O=Heroku; CN=www.example.com
Starts At: 2011-11-01 21:53:18 GMT
...
事例では tokyo-2121.herokussl.com のように、アプリケーションに割り当てられた URL がリストアップされます。このＵＲＬにアクセスしても結果は "no such app(そのようなアプリケーションは存在しません)" というメッセージです -- これは期待通りです。さらにステップが必要なので読み進めてください。
メモ: ヨーロッパのように非標準の地域にあるアプリケーションは、
herokussl.comなどのような別個の SSL エンドポイントを持たないことに注意してください。代わりにエンドポイント URL は例えばexample.herokuapp.comなどのようにちょうどアプリケーションと同じものになります。これはcerts:addコマンドの出力に確実に反映されます。
heroku certs で SSL エンドポイントの設定の詳細を確認できます。
付記: 今までのコマンドでセットアップしてからエンドポイントが利用可能になるまで時間が掛る場合があります。
$ heroku certs
Endpoint Common Name Expires Trusted
------------------------ ---------------- ----------------------- -------
tokyo-2121.herokussl.com www.example.com 2012-10-31 21:53:18 GMT False
certs:info を使うことでいつでも証明書の詳細情報を得ることができます。
$ heroku certs:info
Fetching SSL Endpoint tokyo-2121.herokussl.com info for example... done
Certificate details:
Expires At: 2012-10-31 21:53:18 GMT
Issuer: C=US; ST=CA; L=SF; O=Heroku; CN=www.example.com
Starts At: 2011-11-01 21:53:18 GMT
Subject: C=US; ST=CA; L=SF; O=Heroku; CN=www.example.com
...
もしも herokusll.com エンドポイントを持っているならば、例えば https://tokyo-2121-herokussl.com のように https 経由でサイトにアクセスします。This should throw a cert error saying that the certificate at www.example.com doesn't match tokyo-2121.herokussl.com. This means that you are serving up the cert that you'd expect to serve (just not for the requested herokussl.com domain).
一度、SSL エンドポイントのプロビジョニングとあなたの証明書の確認したら、そのエンドポイントを通ってセキュアなドメインへリクエストが送られるようにする必要があります。 あなたのアプリケーションに CSR を生成したドメインを追加してください。もう既にしているのであれば必要ありません:
$ heroku domains:add www.example.com
Added www.example.com to example... done
note Assuming proper custom domain DNS configuration already, apps located in a non-default region, e.g., Europe, will not have to make any additional DNS modifications. Such apps can skip the remainder of this DNS section.
If you're securing a subdomain, e.g., www.example.com, modify your DNS settings and create a CNAME record to the endpoint.
| Record | Name | Target |
|---|---|---|
CNAME |
www |
tokyo-2121.herokussl.com. |
If you're using a wildcard certificate your DNS setup will look similar.
| Record | Name | Target |
|---|---|---|
CNAME |
* |
tokyo-2121.herokussl.com. |
If you're securing a root domain, e.g., example.com, you must be using a DNS provider that provides CNAME-like functionality at the zone apex.
Modify your DNS settings and create an ALIAS or ANAME record to the endpoint.
| Record | Name | Target |
|---|---|---|
ALIAS or ANAME
|
<empty> or @
|
tokyo-2121.herokussl.com. |
Use a command line utility like curl to test that everything is configured correctly for your secure domain.
callout The
-koption tells curl to ignore untrusted certificates.
$ curl -kvI https://www.example.com
* About to connect() to www.example.com port 443 (#0)
* Trying 50.16.234.21... connected
* Connected to www.example.com (50.16.234.21) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=CA; L=SF; O=SFDC; OU=Heroku; CN=www.example.com
* start date: 2011-11-01 17:18:11 GMT
* expire date: 2012-10-31 17:18:11 GMT
* common name: www.example.com (matched)
* issuer: C=US; ST=CA; L=SF; O=SFDC; OU=Heroku; CN=www.heroku.com
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: www.example.com
> Accept: */*
...
Pay attention to the output. It should print SSL certificate verify ok. If it prints something like common name: www.example.com (does not match 'www.somedomain.com') then something is not configured correctly.
You can update a certificate using the certs:update command with the new cert and existing private key:
$ heroku certs:update server.crt server.key
Updating SSL Endpoint endpoint tokyo-2121.herokussl.com for example... done
If, for some reason, the new certificate is not working properly and traffic to your app is being disrupted, you can roll back to the previous certificate:
$ heroku certs:rollback
Rolling back SSL Endpoint endpoint tokoy-2121.herokussl.com on example... done
If there is no previous certificate, this command will fail.
You can remove a certificate using the certs:remove command:
$ heroku certs:remove
Removing SSL Endpoint endpoint tokyo-2121.herokussl.com on example... done
warning Removing an endpoint does not stop billing. To stop billing, you must remove the SSL endpoint add-on. Remove the add-on with
heroku addons:remove ssl:endpoint.
If you try to remove the SSL endpoint add-on before the certificate is removed, you will receive an error.
When an end-client (often the browser) initiates an SSL request, the request must be decrypted before being sent to your app. This extra SSL termination step obfuscates the originating IP address of the request. As a workaround, the IP address of the external client is added to the X-Forwarded-For HTTP request header.
SSL Endpoint infrastructure is elastic and scales automatically based on historical traffic levels. If you plan to switch a lot of traffic to a newly created SSL endpoint or if you expect large spikes, contact Heroku support so we can help with preemptive scaling. Please give us at least 1 day advanced notice for these types of requests.
In some cases, when running heroku certs it may list your certificate as untrusted.
$ heroku certs
Endpoint Common Name Expires Trusted
------------------------ ---------------- ----------------------- -------
tokyo-2121.herokussl.com www.example.com 2012-10-31 21:53:18 GMT False
If this occurs it may be because it is not trusted by Mozilla's list of root CA's. If this is the case your certificate should work as you expect for many browsers.
If you have uploaded a certificate that was signed by a root authority but you get the message that it is not trusted, then something is wrong with the certificate. For example, it may be missing intermediary certificates. If so, download the intermediary certificates from your SSL provider and re-run the certs:add command.
If you get an Internal server error when adding your cert it may be that you have an outdated version of the Heroku Toolbelt.
$ heroku certs:add server.crt server.key
Adding SSL endpoint to example... failed
! Internal server error.
! Run 'heroku status' to check for known platform issues.
Verify your toolbelt installation and update it to the latest version with heroku update.
Many different file types are produced and consumed when creating an SSL certificate.
- A
.csrfile is a certificate signing request which initiates your certificate request with a certificate provider and contains administrative information about your organization. - A
.keyfile is the private key used for your site's SSL-enabled requests. -
.pemand.crtextensions are often used interchangeably and are both base64 ASCII encoded files. The technical difference is that.pemfiles contain both the certificate and key whereas a.crtfile only contains the certificate. In reality this distinction is often ignored.