Vladimir Vuksan's blog

This is a common problem across many different platforms. You generate a CSR, get a certificate but forget or don't realize that besides installing the signed certificate you need to install the CA (Certificate Authority) Intermediate certificate. As a result some of the older browsers may complain about an invalid certificate or Java code will fail with following error message

Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: CA key usage check failed: keyCertSign bit is not set

Solution is to download the intermediate certificate from the CA e.g. Verisign and GoDaddy and include it with the certificate. For instance in Apache you need to include SSLCertificateChainFile directive with the path to the intermediate certificate. On Cisco loadbalancer you would need to use following Cisco document. Specifically this directive

ACE-1/routed(config)# crypto chaingroup intermed-1
ACE-1/routed(config-chaingroup)# cert intermediate.pem

The chaingroup needs to be applied to the ssl-proxy service in addition to the already configured certificate and key.

ACE-1/routed(config)# ssl-proxy service proxy-1
ACE-1/routed(config-ssl-proxy)# chaingroup intermed-1

If you got your certificate from Verisign you can check whether you installed it properly here

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=ar1130

You can always of course misconfigure things causing lots of time to be wasted. For instance on one occasion a well known managed hosting provider that was in charge of configuring the Cisco load balancer configured the load balancer as follows

crypto chaingroup some.domain.com
   cert some.domain.com.cert
   cert intermediate.cert
ssl-proxy service vip-1.2.3.4-ps
   key some.domain-com.key
   cert some.domain.com.cert
   chaingroup some.domain.com
   ssl advanced-options ssl-parameter-map-1

This is incorrect as the server certificate SHOULD NOT be included in the intermediate certificate chain. Otherwise the helpful Verisign test applet will complain with following message.

Two certificates were found with the same common name. The certificate installation checker cannot determine which is the correct certificate for the Web server. Remove the incorrect certificate and then test again.

Most browsers will work correctly however Java code will exhibit errors from the top of the article. Solution for the above problem is this

crypto chaingroup verisign-intermediate
  cert intermediate.cert

Then included that chaingroup in the ssl-proxy directive. Once that was done the issue went away. Hope this saves someone some debugging time.

While we are on the subject of cloud computing the real problem with it is that rightfully or not it has been portrayed as the computing infrastructure "savior". Just check out the description on Wikipedia (and I am not really picking on Wikipedia just using is as a representative quote)

Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.^[1][2] Users need not have knowledge of, expertise in, or control over the technology infrastructure in the "cloud" that supports them.^[3]

Now that you have heard that kind of a "pitch" it is hardly surprising to hear how great of an idea would it be to move everything off to the cloud thus avoid any capital expenses on equipment, avoid having to maintain the hardware, "unlimited" scalability etc. etc.  Trouble is that that is only a small piece of the whole infrastructure puzzle. In reality the only thing that clouds allow me to do is easily "create" and "destroy" hardware (I guess they abstract hardware). That is certainly a nice feature and no doubt has some value. However clouds don't "automatically" scale (they need some type of middleware to do that), they don't automatically configure themselves (configuration/manual management does that), nor they automatically alert or monitor stuff in YOUR application. You have to do that. Lots of it.

This actually reminds me of the "managed hosting" pitch a lot of the colocation providers will try to sell you on. In some cases they would scoff at the fact that you just wanted plain Jane colocation ie. a cabinet, some amount of power, dual network drops etc. No, they wanted to sell you on stuff like managing your OS/updates, doing back ups etc. so that you can spend your time on more "productive" tasks. That is all nice however that provides very little to no value to me. I can install an OS and all the updates through a mixture of PXEboot, console access and configuration management in less than 10 minutes and I know exactly what needs to be backed up. Do I really need /usr/ backed up on every web machine ? No.

In closing while evaluating cloud computing make sure you really look at what is the problem you are really trying to solve. Clouds do not in themselves provide you with magical ponies. You still have to do most of the work.

Yesterday Slashdot featured a story about a study conducted to evaluate response time of the major cloud infrastructure providers

http://tech.slashdot.org/story/09/08/20/0327205/Amazon-MS-Google-Clouds-Flop-In-Stress-Tests

One of the main findings was that "Response times on the service also varied by a factor of twenty depending on the time of day the services were accessed".

Unfortunately this is not a surprise to me. One of the main issues with shared infrastructure is well ... sharing. There will always be a user or couple users that will for one reason or another use infrastructure inefficiently and this will end up degrading everyone's performance. For example you may have a shared database machine and a user who decides to do full backups daily. Guess what while those backups are running your other users will be severly impacted.

Things are even more complicated in the cloud since you are usually running a virtualized instance which is sharing a piece of physical hardware with other virtualized instances. As such you have very little insight into what other instances are doing and they may be doing a lot to degrade your performance. Even though most of the virtualization technologies promise isolation ie. controlling how much I/O or CPU particular instance gets practice is different. For instance I run a number of Xen hosts/guest and I can see if a particular Xen guest goes crazy ie. starts thrashing the disk all the other Xen guests will start "seeing" higher CPU wait I/Os. This leads me to a story of sorts some time ago I signed up for service from an inexpensive VM vendor (we're talking $10-20/month cheap) so I can run my own web server and mail. Machine was excruciatingly slow most of the time, so slow that typing commands on the prompt took couple seconds yet I wasn't running anything on it. After I installed Ganglia I noticed that CPU WAIT I/O was about 10% most of the time and Load one was average of 4. Remember I haven't even installed anything on this machine. They moved me to a different machine but the same thing happened so I cancelled the service. Company was obviously over subscribing their machines or they had lots and lots of "abusers".

I am not trying to say that clouds are useless but for years (since EC2 was in beta) I heard a lot of preposterous claims about clouds. Even to the point where it was suggested we should run a back up data center on EC2 since it was "cheaper". Even if we could get away from the security concerns ie. not being able to run VLANs, having your traffic cross a shared bridged network interface etc. I just don't see if you needed any type of reliable performance you can rely on clouds to deliver. Sure you could try to get clever with the load balancer but in any case there is always a potential that a set of your visitors will end up on a web server that is affected by someone else's process or worse that all of the sudden your site is terribly slow and there is literally no explanation for it. Try to explain that to your boss .

That said there are obviously cases where clouds could be great ie. when you need to scale quickly from let's say handful machines to dozens of machines then dispose of them when you are done etc. There are likely other scenarios but you really have to evaluate it application by application.

Hijacking this blog for some musings in Croatian

Prije par tjedana stavio sam na

http://radio101.podzone.net/

snimke informativnih emisija zagrebačkog Radia 101. To sam napravio budući da mi je dojadilo što takvo što nije do tada nije učinjeno. To je što se mene tiče velika šteta budući da smo daleke 1996 nakon pokušaja gašenja Radia Damir Džeko i ja pokrenuli podcast Radia 101. To je vjerojatno bio jedan od prvih podcastova na Webu. Nažalost nemam kopije sitea iz tog vremena međutim evo arhive sa archive.org iz 1998

http://web.archive.org/web/19980113130105/vukovar.unm.edu/r101/audio/

Ja sam bezuspješno u nekoliko navrata razgovarao sa ljudima na Radiju da oni preuzmu snimanje i arhiviranje takvih podcastova međutim to očito nije polučilo rezultate. No nije to toliko sada bitno. Što je bitno je što ćemo napraviti u budućnosti. Radio 101 je kultna institucija i informativne emisije Radija su po mojem mišljenju kulturna baština Hrvatske i kao takve ih treba sačuvati za buduće naraštaje. Možda to nekima zvuči bez veze međutim kako budućim naraštajima dočarati što se dešavalo u ranim 2000im godinama nego kroz audio/vizualne snimke. Čitanje suhoparnih vijesti je jedna stvar međutim slušati emisije tipa Parliament Show ili Speaker's Corner gdje obični ljudi iznose svoje tegobe, svoja mišljenja je druga stvar. Također ne znam da li itko može dočarati Aktualac ili Uj Fuj .

Prije par tjedana sam poslao e-mail Silviju Vrbancu budući da me on koliko toliko zna i dobio sam odgovor da se na podcasting radi. Nažalost tu sam priču već čuo pa bih volio na neki način izvršiti pritisak da se to ostvari što prije. Naime ja sam svoj podcasting set up dostupan preko linka http://radio101.podzone.net/ složio za manje od 3 sata. Bravo ja .  Ako nije teško idemo to složiti.

Nakon što se to obavi bilo bi pametno sa primjerice Nacionalnom Sveučilišnom Knjižnicom dogovoriti arhiviranje materijala tako da postoji netko drugi osim Radija koji se o tome brine.