The original SSL protocol has several misconceptions about the way IP 
works baked into the protocol. These create operational difficulties 
that the CA infrastructure has had to adapt to.<br><br>These 
include the assumption that each different Web server has a separate IPv4 address. . This led to a demand for certs that could cover <a href="http://www.example.com/">www.example.com</a> and <a href="http://example.com">example.com</a> in the same 
certificate which seemed perfectly reasonable. Then people realized that 
the same client code would accept a cert with altnames for 50 unrelated 
sites on the same host, which seems less reasonable. While a proper fix 
was proposed in the TLS protocol many years ago the deployment is still 
lacking<br><br>The multiple CNs thing is due to the fact that the early browsers didn't use SubjectAltName, they used the CN and so there are multiple CNs in there. Now Rob tells me that this is no longer strictly necessary but views on necessity may differ in the industry.<br>
<br><br> Cloud hosting is really the same as the traditional 
outsourced hosting model but with the additional factor that not only 
does the Web site not know what else it is sharing a machine with, the 
machine it is sharing can (and does) change on an hourly basis. This is 
essential if people are going to be able to move their computing costs 
around to chase the lowest priced electricity which is going to become 
increasingly important as hardware costs reduce to essentially nil and 
the cost of electricity is the major remaining cost left. Moving to the 
lowest cost power can currently cut electricity costs by 90% at peak, 
that differential is going to go up in future with wind, solar etc. <div><br>The need to support the use case is 
a technical constraint that we are just going to have to live with. But 
we might have options to make it easier to process. For example the CA putting more info in the certs so that they can be recognized as 'the same'.<br><br><br>Another way to look at this problem is that any solution that involves changes to the server and deploying either a new browser or a plug in has the same deployment costs as other security controls such as strong password verification protocols. <br>
<br><div class="gmail_quote">On Sun, Dec 4, 2011 at 1:37 AM, Ondrej Mikle <span dir="ltr"><<a href="mailto:ondrej.mikle@nic.cz">ondrej.mikle@nic.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
I've looked at hosts that send new certs frequently. That is to be distinguished<br>
from 'CDN services' where a server farm sends a couple of certifictes depending<br>
on DNS mapping or load balancer (thus observer sees cert A, then B, ..., then A).<br>
<br>
An example of frequent issuer (i.e. observation timespans don't overlap, cert's<br>
"not_before" roughly matches first observation time):<br>
<br>
Sample 29 certs sent by single host in 71 days period:<br>
<br>
<a href="http://constructibleuniverse.net/frequent_reissuers/frequent_reissuers.txt" target="_blank">http://constructibleuniverse.net/frequent_reissuers/frequent_reissuers.txt</a><br>
<br>
The reason for frequent reissuing is probably that the above certs are used for<br>
some webserver farm (as witnessed by many SANs). I guess each time a new FQDN is<br>
added/removed from hosting, they issue new cert - ones I checked followed that<br>
add/remove SAN/CN patter. Occasionally some get revoked, not sure what's their<br>
criterium for revoking.<br>
<br>
There are around 200 such hosts I know of that get new cert issued at least once<br>
every 4 days, on average (all having the same issuing CA).<br>
<br>
<br>
The issuing frequency might be a good lead for setting DOS-protection limit of<br>
allowed protocol changes per time unit in Sovereign Keys implementation<br>
(original draft had 5 changes per month, IIRC).<br>
<br>
One additional consideration for "pinning cert protocols" (DANE, Sovereign Keys,<br>
Auditable CAs, ...) is that such a frequent change must reflect fast to relying<br>
clients. Shouldn't be really a problem, just a point to note.<br>
<br>
--<br>
<br>
On a side note: while concept of frequent reissuing of certs may not be flawed<br>
per se, though I have a weird feeling about it. Given the number of hosts in CNs<br>
and SANs, it might be easy for human reviewer to miss what is changed (or they<br>
have just good tools to avoid that). Another possibility is that the process is<br>
automated, only automated checks take effect. Any thoughts on how it actually<br>
works? (Their CPS is in French, so couldn't read it).<br>
<br>
Side note 2: is there any resolution how to handle multiple CNs in certificate's<br>
Subject? Latest mention I found about multiple CNs was Dan Kaminsky's paper/talk<br>
(2008?) - basically every TLS implementation does something else. Why are<br>
multiple CNs present/allowed in the first place?<br>
<br>
Thanks for bearing this far (sorry for my "compulsive writing" :-))<br>
<span class="HOEnZb"><font color="#888888">Ondrej<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>