{"id":3,"date":"2007-01-08T23:56:48","date_gmt":"2007-01-08T23:56:48","guid":{"rendered":"http:\/\/patchlog.com\/general\/apache-wildcard-ssl\/"},"modified":"2007-03-28T11:54:55","modified_gmt":"2007-03-28T11:54:55","slug":"apache-wildcard-ssl","status":"publish","type":"post","link":"https:\/\/patchlog.com\/general\/apache-wildcard-ssl\/","title":{"rendered":"apache and wildcard ssl"},"content":{"rendered":"

Today I had a client that wanted me to install a wildcard certificate on his new server. A small job, few minutes I said. Only that it was not really like that. The client had this situation. He had one domain foo.tld and the certificate was for *.foo.tld and a lot of subdomains bar.foo.tld apple.foo.tld and others like that. On each domain there was a different site and the client wanted each domain on to be available over SSL because he had a wildcard certificate for *.foo.com. But the problem was that he only had one ip on that server. From what I read in the apache documentation such thing would be impossible<\/a> . It turns out it's not impossible if you have a wildcard certificate. The ssl FAQ specified two workarounds, #1 use different ports ( not really an option in most cases if you're thinking about serious web business ), and #2 use different ips for each vhost, this may be expensive, hard to get from some ISP, or hard to manage if you have hundreds of domains. I think there should be a line there saying that if you have a windcard ssl you will not need different ips or ports.<\/p>\n


\nThe whole problem exists because of the way that the SSL protocol is designed or at least HTTPS. From what I understand here is how apache and other web servers that implement HTTP\/1.1 work: when a request comes in the web server looks at the Host: header. This header tells the web server the domain that the user is trying to access. Based on the value of the host header the web server will serve files from a certain domain. The HTTPS protocol is HTTP protocol sent over an encrypted connection (SSL), but in order to decrypt the data ( and actually get to the Host header ) the web server would have to know some information about the connection like the cipher suite, the server certificate, the private key, etc. The server does not know how to access that information because such information is specific to each domain and since it does not know the domain for which the connection was made it cannot access it. So the only solution is to use other way of identifying a virtual host like an ip address or tcp port.<\/p>\n

One question comes in mind now: why was HTTPS not designed like we have STARTTLS in smtp where you can communicate with the server in plain smtp and if at some point you decide to go encrypted you just issue a STARTTLS command? that would have been extremely useful in HTTP, the browsers would have just sent the Host: header and then issue a STARTTLS and sent the rest of the data. It would have saved a lot of ip addresses that are used just for serving HTTPS sites.<\/p>\n","protected":false},"excerpt":{"rendered":"

Today I had a client that wanted me to install a wildcard certificate on his new server. A small job, few minutes I said. Only that it was not really like that. The client had this situation. He had one domain foo.tld and the certificate was for *.foo.tld and a lot of subdomains bar.foo.tld apple.foo.tld … Continue reading apache and wildcard ssl<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1],"tags":[20,19,354,363],"class_list":["post-3","post","type-post","status-publish","format-standard","hentry","category-general","tag-apache","tag-open-source","tag-security","tag-web"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pofPh-3","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/posts\/3","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/comments?post=3"}],"version-history":[{"count":0,"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/posts\/3\/revisions"}],"wp:attachment":[{"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/media?parent=3"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/categories?post=3"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patchlog.com\/wp-json\/wp\/v2\/tags?post=3"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}