Hopefully the following questions will make some sense
Assume browser A wants to establish a SSL connection with web server B located at url www.xyz.com. When establishing a connection with B, A receives from the other end a X.509 certificate C. When A receives B's certificate, it checks certificate's CN field to match server B's hostname with domain name specified in certificate's CN field ( this matching is done by the browser and not by the underlying SSL connection). If B's hostname doesn't match with domain www.xyz.com, then A rejects the connection.
a) When WCF client receives a certificate C from a WCF service, does it also check C's CN field to match server's hostname with with domain name specified in CN field?
b) And vice-versa - When WCF service receives a certificate C from a WCF client, does it also check C's CN field to match client's hostname with with domain name specified in CN field?
c) If answer to the above questions is yes, then I fail to see how we can use self-signing certificates SSC with WCF, since to my knowledge SSC's CN field value doesn't match the hostname of a SSC's owner
thank you
You are correct that a self-signed (root) certificate does not often have a common name that matches a host name, although it is definitely possible, but you can use that self-signed certificate to issue a certificate with the common name that you need, eg. a host name.
Take a look at this MSDN entry: http://msdn.microsoft.com/en-us/library/ms733768.aspx
Related
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.
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 work with a web application used by several business units in my organization. The application is accessed using a general URL http://app/ but some of the units use a business friendly URL e.g. http://bu1/, http://bu2/ etc.
The application is soon to be integrated with a portal that requires it to be configured to use SSL and I was advised to request a certificate using a fully qualified domain name so I went with app.company.com. The certificate has been installed on the server and users access it using https://app.company.com/.
However I would also like them to be able to use https://app/ or https://bu1/ or http://bu1/ etc. I'm not clear on how to do this, I think I have the following options:
Should I have requested a certificate without using the fully qualified domain name, just the CNAME?
I keep coming across subject alternative names but they appear to relate to different domains and I'd rather the users didn't need to use a domain at all. 3. Shoud I be looking for a wildcard certificate instead? I think one of the posts on here says they are not recommended.
Do I need a certificate per domain?
Many thanks for any advice!
SSL certificate providers will not hand out a certificate unless it lists a fully qualified domain name that you own through a registrar, so you will not be able to get a signed certificate for https://app/ for instance.
What you need to do in this case, if you really want users to be able to access your app through https://app/, is to create your own self-signed SSL certificate, then insert the certificate into the browser's trusted certificate list on every computer in the company.
For this use case you should set up a certification authority inside your company and issue certificates for the internal domains using your own CA. You'll have to make sure that the computers inside your company trust your root CA certificate automatically.
Also, you can't buy SSL certificates for an internal domain name/reserved IP address anymore.
From the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0 (emphasis is mine):
9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.
Wildcard FQDNs are permitted.
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name. Address or Internal Server Name.
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 requirement to host address-bound or domain-bound certificates in either DNS CERT records or LDAP servers that are discoverable by other parties.
I tried to search on internet about them but didn't got much information.
So basically I need some link or some little explanation about address-bound or domain-bound certificates.
Thanks.
X.509 certificates when used for authentication of servers during SSL/TLS handshake include the server's host name or IP address in Subject.CommonName field and/or in the corresponding field SubjectAlternativeName extension. This information restricts the use of the certificate to certain host and also identifies the host. When the client connects to host A using IP address 1 and receives the certificate issued for host B and/or IP address 2, this is an evidence of either misconfigured server or fake server or stolen certificate. In these cases security of the communication can not be guaranteed.
What you are asking for are not standard terms, that's why you can't find information about them. The certificate can have both host name (or several) and IP address (or several) in it, so the certificate can't be called strictly "something-bound".