Posts Tagged: ssl
r509 and OCSP Responder Updates
I just tagged v0.8 of r509 and v0.3 of r509-ocsp-responder. Here’s what’s new!
r509
- Refactor R509::Validity to support a new #is_available? method
- Serial randomization improvements in CertificateAuthority::Signer
- Better documentation
- Added ::load_from_file static method to more objects
- r509-parse binary for quick parsing (alpha, will be improved)
r509-ocsp-responder
- Updated the /status endpoint to make it simpler to replace the redis backend with an alternate R509::Validity implementation
- Print config on startup
- Support reloading and printing of config to logs via kill -USR2 signal
- Statistics collection now supported via r509-ocsp-stats
- New code path for ~100x faster config lookups (this will not be used until at least Ruby 2.0. I have a pending patch that needs to land in trunk and eventually get released)
- Changed default log levels
- Switch to using hiredis for redis lookups (if you’re using the redis backend)
r509-validity-redis was also updated to work with the latest OCSP responder release if you’re using the redis backend.
Ruby OCSP Responder
I’ve been remiss in not mentioning this project, but along with the open source ruby certificate authority project r509 we’ve also built and released a full open source OCSP responder written in ruby. r509-ocsp-responder, as we’ve catchily named it, is designed to conform to RFC 2560 and 5019 and allow you to quickly and easily get a full OCSP responder up and running with a (relative) minimum of configuration.
r509-ocsp-responder is designed to be a “known good” responder. This means it will respond with an UNKNOWN if the responder is queried about a certificate it is unaware of even if it is configured to respond for that CA. This is in contrast to many responders, which are designed as “known bad” and will reply VALID unless the certificate is known to be revoked. We have written a redis-based validity checker (r509-validity-redis) that you can use, or you can easily write your own writer/checker backend.
If you happen to want to build an entire CA stack, we’ve got one last project (+ some middleware) for you. r509-ca-http is a RESTful interface for issuing certificates. It also works with r509-middleware-validity to automatically write issuance/revocation data to the OCSP responder’s redis DB.
We’ll be improving the documentation around these ancillary projects shortly, but feel free to dive in now (as several of you already have!).
SNI in iOS 4.0
iOS 4.0 supports SNI, which makes it the first mobile OS to support the server_name TLS extension. Hopefully Android, WebOS, WM7, et al follow suit!
(Oh, and I’m not dead. WP 3.0 comes out shortly so expect a major CDN Tools update as well as a brand new plugin!)
SNI Support in Chromium OS X
As of r39934 Chromium now supports the server_name TLS extension (server name indication) in OS X (latest build). This support requires OS X 10.5.7 or later. Hopefully it’ll make its way into a dev/beta/stable release of Google Chrome itself soon.
For those who are more curious than they ought to be about how I wrote this patch… Apple added support in their Secure Transport library for the server_name TLS extension, but has not updated their documentation. As of 10.5.7 (or possibly 10.5.6) the SSLSetPeerDomainName function — which is ostensibly used for OS level certificate verification — causes OS X to send the server_name extension in the TLS client hello. However, since Chromium doesn’t use OS X’s built-in verification it wasn’t passing this data through prior to the patch.
To test you can hit up my IDN SNI site https://☣.ws/ or https://alice.sni.velox.ch/. The former will throw a certificate error if you are on a non-SNI enabled browser and the latter will have text stating that the SNI extension is missing.
SSL VHosting On The Same IP (aka SNI)
Server Name Indication (SNI), an extension to TLS, allows browsers that support it to connect to SSL hosts that do not have dedicated IPs (much like standard http virtual hosting has worked for years). This extension, however, must be supported on both the server and client side. Microsoft has not yet chosen to support it (maybe IIS 8?), but the Apache project did with the 2.2.12 release. Recently, Ubuntu 9.10 Server became the first server distribution to ship with Apache and OpenSSL built with the appropriate flags, so if you’d like to follow along you can use a 9.10 VM.
In the ideal case everything is the same as a regular vhost, but you’ll first need to enable SSL. On Ubuntu this requires you to run a2enmod and type “ssl”. After that you’ll need to add
NameVirtualHost *:443 |
to the root conf, then make your VirtualHost much like a normal one. A very basic pair of vhosts is seen below.
<VirtualHost *:443> ServerAdmin webmaster@localhost DocumentRoot /my/doc/root ServerName mydomain.com SSLEngine On SSLCertificateFile /path/to/domain.crt SSLCertificateKeyFile /path/to/domain.key </VirtualHost> <VirtualHost *:443> ServerAdmin webmaster@localhost DocumentRoot /my/doc/root ServerName mydomain2.com SSLEngine On SSLCertificateFile /path/to/domain2.crt SSLCertificateKeyFile /path/to/domain2.key </VirtualHost> |
These vhosts should be placed in different includes ideally, but it isn’t required. If you just want to test with a self-signed certificate you can create one with
openssl req -new -nodes -keyout mykey.key -out mycert.cer -days 3650 -x509 |
You’ll need to specify the domain name you want in the “Common Name” section.
Once you’ve got all this done you can restart apache and test it out! If you test on a browser that doesn’t support SNI (IE on XP) you’ll get the SSL cert for the first vhost apache parses. To disable accessing it on non-SNI hosts you can add
SSLStrictSNIVHostCheck on |
to the root conf. This will cause a 403 error for those browsers.
If you’d like to see an example implementation of SNI you can check out my IDN domains https://☢.ws/ and https://☣.ws/. These sites are hosted on the same IP with different SSL certificates. I have strict host checking turned on so visiting them with a non-SNI capable browser will result in a 403 error.1
- See the Wikipedia article about Server Name Indication for more information on supported browsers. ↩
Firefox Autoenrollment With A Microsoft CA
If you’re running a Microsoft CA and you want to be able to accept enrollment requests from clients supporting keygen (Firefox, Safari, Opera, et cetera) you’ve probably found that the /certsrv/ page allows enrollment, but the requests fail when you attempt to issue the certificate. This is because the server is not parsing the subject attributes from the request. To fix this, run the following on your server as administrator on the command line.
certutil -setreg ca\CRLFlags +CRLF_ALLOW_REQUEST_ATTRIBUTE_SUBJECT |
You can also set your server to auto-issue on request for certain certificate profiles. To do this add the CA snap-in and get properties of your CA. Under the policy module tab click properties again and click the “Follow the settings..” radio button.
