I want to generate some certificates that are NOT linked to a domain name. The reason is I dont have a domain name for my api yet. Could someone explain what I put in for cn if there is not domain name at all? I am just trying to test out some services over https. Thanks
If you access a resource by https:// then the client will expect the domain name from the URL to be included in the certificate. If the URL does not contain a domain name but an IP address then this one is expected - as subject alternative name with type IP. See Is it possible to have SSL certificate for IP address, not domain name? and How to generate a Self Signed SSL Certificate bound to IP address? for more about this.
Certificates without domain names or IP address are possible in other use cases but not in this one, at least as long the client is properly validating the certificate.
Related
Currently in the process of moving an existing public facing site from Azure to our internal network. In order to retain the validity of the SSL (https) protocol I had to request another certificate for the the machine where the new site will reside.
I installed the cert on the system and it says it installed successfully but the site is showing a Certificate error in IE.
So I'm wondering if the fact that the CSR was created using the DNS name and the DNS hasn't yet been redirected to the new location; is the reason the Cert Error is being displayed?
The only way to access the new server is via IP address externally, not by the DNS name.
Does the site certificate get bound during creation to the DNS name of the server where it is supposed to reside or by the encrypted signature of the actual machine when the CSR (Certificate Signing Request) is generated?
Or is it both?
The only way to access the new server is via IP address externally, not by the DNS name.
I'm not fully sure what you are asking. But my interpretation of the question is that you have created a certificate for some DNS name (i.e. example.com) but then try to access the site by IP address since the DNS name is not available yet. And then you wonder why the browser complains (with an error you unfortunately not include in your question).
If my interpretation is correct then the reason for the browser error is that the hostname in the URL (i.e. the IP address you used) does not match the subject(s) of the certificate, i.e. the DNS name. This validation of name in URL against subject of certificate is an essential part of the certificate validation.
I would like to generate an SSL Certificate Signing Request (CSR) for the procurement and installation of an SSL certificate.
My question surrounds what we should enter for the FQDN given our specific situation
We will be hosting a domain name 'www.foo.com' within our server.
This domain will be accessed via a different domain 'www.bar.com' which will be CNAMEd to our hosted domain 'www.foo.com'
We want the client to see that the domain 'www.bar.com' has a valid SSL certificate.
So my question is, when we generate the CSR do we need to enter 'www.foo.com.' or 'www.bar.com.' as the FQDN for hostname in the CSR?
Edit: It is not intended that the domain name www.foo.com will ever be used to access the website.
Looking at this answer https://serverfault.com/questions/494654/which-fqdn-hostname-to-use-for-ssl-certificate-signing-request-when-using-a-cna it looks like in our CSR we should be using 'www.bar.com.' but confirmation from a suitably qualified person would be appreciated!
www.bar.com
Whatever FQDN the client requests in the browser should be in the subject of the certificate - no matter what happens in "the background", be that in terms of DNS resolution, backend proxying etc.
As long as the browser thinks it's talking to www.bar.com, the browser will also expect www.bar.com to be in the certificate
A PCI Compliance scanner is balking that the self signed SSL certificate protecting secure access to Plesk Panel contains a name mismatch between the location of the Plesk Panel and the name on the certificate, namely the self-signed cert's name is "Parallels" and the domain to reach Plesk is 'ip address:8443'.
So I figured I would go ahead and get a free SSL certificate to try to fiddle with this error. But when I generated the certificate I used my server domain name as the site name when I generated the certificate. So if I visit 'domain name:8443' all is fine, no ssl warning. But if I visit 'ip address:8443' (which I believe is what the scanner does) I get the certificate name mismatch error, Digicert's ssl checker says that the certificate name should be the ip address.
Can I even generate a certificate whose common name is the ip address? I am tempted to say I should just do what the PCI scanner accepts, but what is really the correct common name to use? Anybody run into this issue before?
You can try a Subject Alternative Name extension for the IP address. Also, you can keep "Parallels" as the Common Name, and add a Subject Alternative Name extension for the DNS name, which should be the preferred match (i.e. higher precedence than Common Name.)
Can I even generate a certificate whose common name is the ip address?
No, you shouldn't. While this may work with some browser, this will fail with clients that are compliant with the HTTPS specification:
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.
If you want to use an IP address in a certificate, you must have it in as a Subject Alternative Name (of type IP address, not DNS). You can check this question for details on how to do this.
However, more importantly, it sounds like in your case you don't need to use the IP address at all.
The purpose of certificate name verification is to check that the identity in the certificate matches the identity as requested by the client. (Reverse lookups or other names don't matter.)
The fact that you've already configured your system for your domain name and that it works when using the name means that it's already configured properly. It sounds like your giving your scanning tool the IP address of what you're trying to scan (which isn't what the clients would normally use): make it use your host name instead. That's what the scanning tool should try to compare anyway.
Can I even generate a certificate whose common name is the ip address?
(Thanks Bruno for pointing to right solution) There is enough to set subjectAltName in CSR.
IFAIK there is no such option in Plesk, but here good instruction for openssl http://apetec.com/support/GenerateSAN-CSR.htm
I have a site that has subdomains for each user and a wildcard SSL Cert
https://user1.mysite.com
https://user2.mysite.com
The question is can someone set a cname record such as user1.theirsite.com -> user1.mysite.com and have it still use https?
Will it work if they install a SSL Cert on their server to secure the connection?
Thanks
The best way for this to work is if they arrange with you to have your SSL certificate include their "alias" as a Subject Alternate Name extension in your X.509 certificate.
This is the approach used by some CDNs when they host https sites for clients - they put all of the known site names that are hosted on one server in one large SSL certificate, and then the clients use CNAMEs to point their domain at the right CDN server.
The host name and certificate verification (and in fact, checking that SSL is used at all) are solely the responsibility of the client.
The host name verification will be done by the client, as specified in RFC 2818, based on the host name they request in their URL. Whether the host name DNS resolution is based on a CNAME entry or anything else is irrelevant.
If users are typing https://user1.theirsite.com/ in their browser, the certificate on the target site should be valid for user1.theirsite.com.
If they have their own server for user1.theirsite.com, different to user1.mysite.com, a DNS CNAME entry wouldn't make sense. Assuming the two hosts are effectively distinct, they could have their own valid certificate for user1.theirsite.com and make a redirection to https://user1.theirsite.com/. The redirection would also be visible in the address bar.
If you really wanted to have a CNAME from user1.theirsite.com to user1.mysite.com, they might be able to give you their certificate and private key so that you host it on your site too, using Server Name Indication (assuming same port, and of course same IP address since you're using a CNAME). This would work for clients that support SNI. There would however be a certain risk to them in giving you their private keys (which isn't generally recommended).
The following is set up and working:
DNS entry for a.corp.com -> CNAME b.corp2.com -> A 1.2.3.4
The haproxy at 1.2.3.4 will serve up the cert for a.corp.com and the site loads fine from a webserver backend.
So, on your server you will need user1.theirsite.com cert and it will work.
In a web application, if it doesn't have a domain name (like a web service for example), can you still add a SSL certificate to a IP address?
If yes, how?
You can easily put an ip address into the CN (common name) of an ssl certificate by the same procedure you would use for an ordinary hostname (ssl certificates contain hostnames, not domain names).
How this is done precisely in your case cannot be answered, since you have not stated what your case is.
Browsers should match the CN of a certificate against what the user has put into the URL bar. If it's an ip address, it's an ip address.
This site offers certificates for IP addresses. You wouldn't be able to (properly) use a certificate for a domain name for an IP address, however.
Yes you can, but it isn't common, probably isn't portable, and usually isn't a great idea...Public IP Address
An SSL certificate is typically issued to a Fully Qualified Domain Name (FQDN), but issuers can still offer SSL certificates for a public IP address, typically declared in the CN and SAN values of the certificate, since historically these are referenced varyingly by different flavours/versions of browser. However the facility might only be offered in premium products, eg an 'Organisation Validated' (OV) Certificate covering a whole organisation, or an 'Extended Validation' (EV) Certificate which requires rigorous vetting when acquired.
Private IP Address Space (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8)
In November 2015, the CA/Browser Forum prohibited the use of internal server names and reserved IP addresses in publicly-trusted SSL Certificates. However some issuers do still offer 'Intranet Certificate' services that allow enterprises to continue to issue SSL to internal server names and reserved IP addresses without the need to run their own CA or use self-signed certificates, instead using the issuer's own non-public CAs.
In this scenario it's possible to store internal server names and reserved IP addresses in the CN and SAN values of the certificate. These may also allow options which would otherwise not be permitted under public hierarchies including the use of SHA-1 and 4-5 year certificates etc, furthermore, you can mix internal, FQDNs, sub-domains, wildcard, and public IP addresses in a single certificate under a non-public root.
There's some good information here:
https://www.thawte.com/ssl-digital-certificates/technical-support/browserfaqs.html
I'm almost certain you need a domain to go with the SSL.