Having selected their target, the team needed to generate their rogue certificate to transfer the signature to. They employed the processing power of 200 Playstation 3s to get the job done. For this task, it’s the equivalent of 8000 standard CPU cores or $20K of Amazon EC2 time. The task takes ~1-2 days to calculate. The tricky part was knowing the content of the certificate that would be issued by RapidSSL. They needed to predict two variables: the serial number and the timestamp. RapidSSL’s serial numbers were all sequential. From testing, they knew that RapidSSL would always sign six seconds after the order was acknowledged. Knowing these two facts they were able to generate a certificate in advance and then purchase the exact certificate they wanted. They’d purchase certificates to advance the serial number and then buy on the exact time they calculated.
The cert was issued to their particular domain, but since they controlled the content, they changed the flags to make themselves an intermediate certificate authority. That gave them authority to issue any certificate they wanted. All of these ‘valid’ certs were signed using SHA-1.
If you set your clock back to before August 2004, you can try out their live demo site. This time is just a security measure for the example and this would work identically with a certificate that hasn’t expired. There’s a project site and a much more detailed writeup than this.
To fix this vulnerability, all CAs are now using SHA-1 for signing and Microsoft and Firefox will be blacklisting the team’s rogue CA in their browser products.