Can I generate CSR for remoted server and what server I should use(thin,mongrel)?
I am moving my app into production and need help in generating CSR. I created a private key and followed these steps:
- Created private key
- Entered passphrase for it (openssl genrsa -des3 -out domainname.key 1024)
- Created CSR (openssl req -new -key domainname.key -out domainname.csr)
- In the CSR, I entered all the info. Common name was in format: XX.XXX.XXX:3000, where X is number.
Finally, I generated the CSR, but at this stage my application is on a remote server with IP address http://XX.XXX.XXX.XXX:3000/ and on thawte.com when generating the trial SSL it shows me the error:
The Common Name in the CSR is invalid.
Has anyone had a similar task and can advise me what I have done wrong?
Second question: What server can you recommend to me and accordingly what Web Platform (when generating SSL) I should choose in the list ?
Common names do not contain port numbers or colons such as :3000. They should not be an IP address. They also do not contain protocol identifiers such as https://.
If memory serves me correctly, numbers on their own are not valid as a domain name (although they can be for subdomains) and there is no top-level domain that is just a number. Your common name of XX.XXX.XXX:3000 where X are numbers is not an IP address or a domain name.
The common name should be nothing but the fully qualified domain name that the certificate is to be used for.
You can use *.example.com for the common name if you are requesting a wildcard certificate.
If your app is running on port 3000, you should request your certificate normally, without the port number, and then tell the clients to use port 3000. If the client is a web browser, this is done in the URL: `https://www.example.com:3000/"
The choice of "Web Platform" is optional and allows Thawte to give you the files in the format required by that software. For instance, nginx requires that the certificate and any chain certificates are in the same file, in the right order. Apache can have them in separate files and import them both with SSLCertificateFile and SSLCertificateChainFile. If your website is running on a well-known HTTP server that's in the list, choose that software. If you wrote it yourself or it's custom software written for you and it isn't in the list, consult the manufacturers of the software.
Common name was in format : XX.XXX.XXX:3000, where X is number
Firstly, the host name or IP address in the certificate mustn't include the port.
Secondly, assuming XX.XXX.XXX is an IP address, IP addresses must be in a Subject Alternative Name entry of IP address type (not DNS type, and not in the Subject DN's CN). See RFC 2818:
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
Some clients are more relaxed about this, but that's no reason to get a non-compliant certificate.
I'm not sure Thawte will issue you a certificate for an IP address anyway, since it's quite difficult for them to check who the IP address belongs to.
(I'm a bit surprised that they even bother looking at the CN, since all they really need is to grab the public key from the CA, and issue a cert with only whatever they've independently validated, anyway.)
The Common Name field should be the Fully Qualified Domain Name (FQDN) or the Web address for which you plan to use your Certificate, e.g. the area of your site you wish customers to connect to using SSL. If the Web address to be used for SSL is www.example-name.com, ensure that the common name submitted in the CSR is www.example-name.com; similarly, if the Web address to be used for SSL is secure.example-name.com, ensure that the common name submitted in the CSR is secure.example-name.com.