PCI Compliance and SSL Certificates

[chris1911]

My company is going through PCI Compliance right now and we have an issue. We have our domain www.ourdomain.com for example and our server locally (it's really just a workstation in our workgroup) that we download our orders to. It also downloads credit card information, customer information, etc. We got a response from our PCI scan saying that port 443 doesn't have a trusted SSL cert because it's self signed by our Sonicwall. We use LogMeIn on this port and must have it.

We purchased a SSL certificate from GoDaddy but when generating the CSR request from our Sonicwall we used our WAN IP from the Sonicwall as the Common Name. GoDaddy says you can't use IANA IPs as the CN any longer and that you have to have a domain name associated with it. Does anyone know what I should do here? The GoDaddy site says we can check a box that says it will be used on an internal network but I don't think they will be able to verify the cert that way when they do the port scan. Any advice would be greatly appreciated.

-Chris

[ocabj]

Do you only have one single publicly addressed IP and all of your hosts are NAT'ed behind that single IP (SonicWall device) and using RFC 1918 addresses?

If so, does that single publicly addressed IP have ourdomain.com as it's host/domain name binding?

If so, shouldn't you just request the certificate with ourdomain.com as the CN and then use that certificate on the web server behind your SonicWall device?

[bigbearbear]

You need to do as they say, generate the CSR using your company domain name. For example, if you own a domain ourdomain.com, you can generate a SSL certificate with a Common Name (CN): web.ourdomain.com or www.ourdomain.com. Basically any name plus a dot (.) followed by your domain name.

After you have done this, you will also need to register your domain name with your DNS provider so that the full address (eg. web.ourdomain.com or www.ourdomain.com) resolves into the IP address on your Sonic firewall.

[chris1911]

Originally Posted by ocabj

Do you only have one single publicly addressed IP and all of your hosts are NAT'ed behind that single IP (SonicWall device) and using RFC 1918 addresses?

If so, does that single publicly addressed IP have ourdomain.com as it's host/domain name binding?

If so, shouldn't you just request the certificate with ourdomain.com as the CN and then use that certificate on the web server behind your SonicWall device?

ourdomain.com is hosted off site and our network just has one static IP to our router. I ended up getting it solved though after about 8 hours of banging my head against the wall.

I took one of our domains not in use and created an A Record for our IP. Then I just submitted the CSR with the CN for the new domain and it all appears to be working after having to spend about 2 hours reconfiguring our entire router

[mud99]

You should inquire with your merchant. You can get a PCI compliance waiver, and it only costs a few more dollars than doing the routine scans.

Our company has been out of PCI compliance for years and I couldn't be happier!

[EurekaPayments]

There is PCI Insurance available, but the risk of a data breach is well worth becoming PCI Complaint. If not for the compliance itself for the purposes of avoiding crazy fees from the card brands should a data breach occur.

If you have PCI Q's or merchant account Q's i would be happy to assist.

Any CalGunner opneing a merchant account with my company we also contribute 10% of revenue generated to CalGun Foundation....

[chris1911]

We ended up getting it taken care off. We had to use one of our inactive domains to our routers static IP and then generate the SSL CSR using that domain. It ended up working out alright it was just a pain to deal with because we didn't want to use a domain to our router and apparently there has been an industry wide shift for SSL CAs to not issue SSL certs for IPs anymore.

[Jason95357]

Just my two cents, but hosting any sort of PCI stuff and doing it correctly is a major pain (at least at the merchant level of transactions/dollars we were dealing with). Our processor didn't charge anything different to have the payment form hosted by them (as opposed to our server forwarding the results of the form to them via a back-end connection), so we went that route. Basically we have an iframe that loads from their page when they go to purchase and after the purchase the iframe is redirected back to our page. The customer doesn't know they ever left our site, but as far as PCI is concerned it is all third-party hosted (our server never sees any payment info), so the only thing we have to do for PCI is annually have a statement from the processor that they are PCI compliant and we are done.

[EurekaPayments]

Originally Posted by Jason95357

Just my two cents, but hosting any sort of PCI stuff and doing it correctly is a major pain (at least at the merchant level of transactions/dollars we were dealing with). Our processor didn't charge anything different to have the payment form hosted by them (as opposed to our server forwarding the results of the form to them via a back-end connection), so we went that route. Basically we have an iframe that loads from their page when they go to purchase and after the purchase the iframe is redirected back to our page. The customer doesn't know they ever left our site, but as far as PCI is concerned it is all third-party hosted (our server never sees any payment info), so the only thing we have to do for PCI is annually have a statement from the processor that they are PCI compliant and we are done.

AGREED - most gateways out there host the actual transaction data on their server which removed nearly all PCI liability. However, the merchant STILL has to be PCI Complaint. But as opposed to major work and network scans etc, most merchants (unless you are EXTREMELY big volume) simply need to complete a SAQ (Self Assessment Questionnaire) that attest to the fact that transaction data if off loaded to the gateway and the merchant does not store any card holder data.

PCI goes beyond the electronic transmission of data. To be PCI Complaint you have to be sure not to store cardholder info even on paper in theoffice. If you get faxed orders for example with full cardnumbers, SHRED EM as soon as you enter the sale into the gateway.

PCI is a mess if you are storing data..... fairly easy to deal with is using a gateway to store the data. Also many processors are charging a "PCI MONTHLY FEE" if you are compliant PLUS a "NON COMPLAINT FEE" if you are not. Often this 20-30 fee can be eliminated simply by completing the SAQ...

Business owners... check you CC Processing statements... if you are being charged a PCI NON COMPLIANT FEE.... you are wasting money...

[Jason95357]

True regarding staff training - our staff are trained we are not allowed to handle credit card data in any fashion, period.