Unable to install WildCard Certificate for ASA 5512-x

[pboehm]

Have a customer who we manage an ASA 5512-X for.  I am configuring a Wildcard Certificate for AnyConnect. They have a wildcard certificate purchased through Godaddy.com.  I am utilizing ASDM 7.3 for the installation of the certificate.  I added the Identity Certificate ASDM_TrustPoint0.  Checked the radio button "Add a new identity certificate:"  Named the Key Pair WildCard, and set the size to 2048.  I also changed the "Certificate Subject DN: to CN=cityvpn.wirapids.org.  There were no other attributes to add.  I also changed the FQDN under the advanced tab to the same cityvpn.wirapids.org.  Then clicked Add Certificate.  Successful

Under CA Certificates I added the certificate from file.  Which I added the bundle.crt from Godaddy.  Certificate was added successfully.

Going back to Identity Certificates.  I click on install.  Install from a file.  Which I tried the other crt file and the bundle file from Godaddy.  I get an Error: Failed to parse or verify imported certificate.  With the other .crt file from Godaddy I get the same error, but "Certificate does not contain device's General Purpose Public Key."

Not sure what to think.  Any suggestions or help would be great.  Thanks

Paul

[Marvin Rhoads]

You need to bundle the wildcard certificate together with the private key that was used in the Certificate Signing Request (CSR). Folks typically do this using something like openssl.

There are several articles on how to to this. Here's a link to one elsewhere on this forum.

[patoberli]

You should never ever get a wildcard certificate. Because if that certificates private key gets stolen, the thief can impersonate all ssl-protected services. The clients view them as valid resources, because the certificate is correct. The only thing to do then, is to revocate the certificate, which will cause you to get a new certificate installed on ALL services that you had protected with the wildcard one.

Even worse, most broswers (besides IE) ignore certificate revocation lists in various cases!

[roy.olsen]

I agree, it is important to understand the inherent risk of sharing private keys across unrelated services or varying security classifications.  A widely used key may indeed be a bad idea if site impersonations (or session replay if you lack PFS) are of any significant concern to your operation. On the other hand, it is likely best to never say never, especially when there are wildcards at play. 

Wildcard certs certainly appear well suited for isolating individual instances of a service at the virtual host level. No additional configuration required for certificates or even TLS endpoints as you add or remove installations.  This can be put into good use when designing for adaptive capacity or simply to support basic customer isolation by host name. Eg. https://customer.zendesk.com

Disregarding the availability of wildcard certificates for a moment, how would you suggest deploying a thousand name based virtual hosts to a set of traffic managers, content switches or load balancers?

[Marvin Rhoads]

If you're deploying a thousand of anything, you probably have some sort of automation and/or orchestration system. Puppet, Chef, Ansible etc.

In such an environment, you would be well-served to look at certificate services from a provider like Lets Encrypt. I haven't done it myself since I'm more of a network vs. a server type but I have heard some people have had good success using such a service to automatically request and deploy certificates, including auto-renewal.

Have a look at https://letsencrypt.org/

[roy.olsen]

I really like Lets's Encrypt and have used it for my personal servers for some time now.

Other than the significant task of renewing these certificates  don't see any technical killer arguments against using the free certificates in many  a small business context, but where I work we serve a market where many prefer to be associated with more familiar and trusted brands such as Verisign, Oracle and Cisco. I think most clients even prefer that their service providers run certificates identity validation beyond domain control 

Anyway, wildcard certificates appear to fit the use-case  quite nicely, easily carry familiar brand names  and  works toward reducing the frequency of configuration changes on the network edge.

[Abaji Rawool]

If you have used CSR to generate the wildcard cert, install the ID cert first from the bundle and the CA cert should be installed automatically. If the bundle is correct.

or you can install them one by one as described here :http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/98596-asa-8-x-3rdpartyvendorcert.html