Implementing Verisign PKI

The past couple of weeks I’ve been working on implementing a PKI solution from Verisign.
Its been a long road. Its been a couple years at least since I first started working on PKI implementation products. The purchase was delayed a couple of times. Then the implementation was delayed. Once we got to doing the implementation, it was rather straightforward. I’m happy with the way things are going, and I’ll be happier as we get the product deployed to larger test groups.
There are a couple of things we still need to work out:
1. I’ve got a couple users where they could enroll for the encryption certificate and it was escrowed correctly, but there was a cipher issue and the certificate couldn’t be added to the browser.
2. The last two modays I’ve found the Luna SA (a HSM) were not bound to Active Directory. I’m still gathering information on this. I t hink when the domain controller reboots, the Luna fails to rebind on its own, but I need to verify this.
3. On the RA, if I do a service verification (-sV) nmap scan on its port (2003/TCP), the memory spirals out of control. Multiple scans will crash it. That issue will hopefully be fixed in the next version. For now, I’m just going to have to avoid scanning that port.
Professional Services said, “[the application] was designed to be deployed in a control setting. The service wasn’t designed to be robust.”
I really had a problem with that statement. I hope that was a off the cuff remark rather than official Verisign position. Internal networks behind a firewall aren’t guaranteed to be a pristine environment. I’d like my security related services to assume they are going to be attacked and be able to preserve confidentiality integrity and availability.
Unfortunately we aren’t well segmented internally. Perhaps I should consider using the Windows Firewall so that only devices that need to talk to the server on that port (such as the web server) are able to do so.
I am happy with the implementation. Any issues we’ve had are being address.