I am using a certificate with subject alternative names in the "Subject" field instead of x509 extensions.
A java client that I use still fails connecting to https url complaining that hostname in certificate didn't match. My understanding is as long as the hostname is listed in Subject Alt Names it should work.
Here is the format of the Subject field in the certificate
C=US,ST=.......CN=x.yz.com/emailAddress=a#b.com/subjectAltName=DNS.1=x2.y.com,DNS.2=x3.y.com
Is it necessary to define SAN as X509 extensions
The subjectAltName is expected to be an X509v3 extension of the certificate, not a part of the Subject field. Therefore, if you listed the SAN names into the Subject, your certificate is invalid.
Here's an example of a certificate that defines an SAN. This answer contains the list of allowed fields for a subject.
Related
The client certificate works if I generate the client certificate as below
openssl req -config openssl.cnf -new -nodes -subj '/C=RO/ST=Bucharest/L=Bucharest/O=XXX/emailAddress=wdw#gmail.com/CN=192.1.61.7' -keyout private/client.key -out client.csr
192.1.61.7 is the IP address of my client which uses the generated client certificate.
I want the client certificate to be used by machines from any IP addresses.
I tried CN=*.*.*.* and CN=*, neither works.
The server side is logstash tcp input filter which I can't change it.
Must the client certificate be bind to a specific IP or domains? how to generate a client certificate not binding to any IP and domain?
Must the client certificate be bind to a specific IP or domains?
No. But how things are handled depends on the PKI you are running. Each PKI can be different.
You can identify a user with the traditional Distinguished Name (DN) from RFC 4511, like Organization (O) and Organizational Unit (OU). Or you can identify them with an alternate name.
Here are the ways you can identify a subject by an alternate name. Its from RFC 5280, Section 4.2.1.6, Subject Alternative Name:
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
In the above, you are used to using dNSName for server certificates. Client certificates can use rfc822Name, directoryName, otherName and other GeneralName.
What you use depends on your PKI. I believe Microsoft client certificates use otherName and a custom OID. Also see How to encode a username in PKIX certificate on the Information Security Stack Exchange.
You might also want to search for Client Certificate GeneralName and do some reading.
How to generate a client certificate not binding to any IP and domain?
It depends on the tools you are using and your PKI.
At minimum, you are probably going to have to stop using the openssl command line tool without a CONF file because its too limited. You cannot set subject alternate names through command line options. Instead, you are going to have to use a CONF file.
When I try to upload an SSL certificate for my Bluemix custom domain, I receive this error message:
BXNUI2072E: The intended host name, *.<custom_domain>, is not a subject within the certificate.
How can I go about getting my certificate uploaded successfully and avoid this error?
Thanks!
I learned that the problem here was due to the certificate I was using, which was for a single, specific domain. Bluemix supports only wildcard certificates, that's a key point.
I got around this by replacing my single domain certificate with a wildcard certificate.
To generate a wildcard certificate, I needed to specify a wildcard domain by adding an asterisk (*) and a period (.) in front of my custom domain name.
In the example that follows I used OpenSSL to generate a self-signed wildcard certificate. I've generalized the example but simply specify a wildcard domain for the Common Name field.
Common Name (e.g. server FQDN or YOUR name) []:*.<custom_domain>
I tested and succesfully got this to work for both a self-signed certificate and a certificate signed by a certificate authority.
Generating a CSR needs the server-name, organization, country etc. The server-name is used in SSL to make sure the server you are talking to is the server which was certified. Question is (1) what is the relevance of server-name if I use a certificate for code-signing?
Code signing certificates are different from SSL certificate only in flags. Rest is all the same. Now if I take a SSL certificate issued to foo.com and install it on bar.com then it wont work. What about code signing certificate? If a take a code signing certificate issued to foo.com and install it on bar.com and sign DLLs or JARs from there, then would there be any problem (2)?
I guess there should not be any. I do not have such a certificate so I cant test it, but by theory should there be any problem?
what is the relevance of server-name if I use a certificate for code-signing?
there are no dependencies. However, proper subject field will help to identify the original publisher.
then would there be any problem
no. There is no other subject name to compare. For code signing certificates, subject may be any, it must be just descriptive.
I am reading the following article about HTTPS:
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
I do understand how we can verify that a signature was truly created by VeriSign.
But how can we know that VeriSign created this signature for this specific domain that we are connected to (or actually for this certificate)?
Since I can see the certificate, including the signature, what stops me from creating my own certificate, replacing the signature with the one I saw on the Amazon.com certificate, and pretending to have a certificate signed by VeriSign?
Since I can see the certificate, including the signature, what stops me from creating my own certificate, replacing the signature with the one I saw on the Amazon.com certificate, and pretending to have a certificate signed by VeriSign?
A certificate has a subject, public key, issuer and signature (among other fields). For example, a subject might be example.com (a DNS name) or joe#example.com (and email address), and the issuer might be Startcom. The issuer's signature binds the subject's public key to the subject. That's all a certificate does: it binds a public key to an entity through an authority's signature. The authority is often called "trusted" or "trusted third party".
So the person who is validating the certificate you are trying to forge will extract the issuer, get the issuer's public key (that's in a different certificate), and then use the issuer's public key to verify your certificate data. Since you forged the signature (i.e., used a different public key than that of the issuer), the signature verification will fail.
Because the public key with which you can verify the signature is part of the certificate and also part of the signature. So you can't change any of those things without breaking the signature.
#gilden But I do not try to create a new signature. I use (almost) exactly the same certificate amazon sent me when I tried to https-contact its website (so same signature and same public key as on amazon's cert). The only thing I change on that cert is the name field (i.e. the name of the website/computer who was given the authority by the signer to use this cert to authenticate itself). So I'm going to change this field from "amazon.com" to "rapt.com". Now I can use this cert to convince people rapt.com is a trusted website. What in the SSL algorithm is going to make me fail in my scheme?
Then the browser/client will use the amazon.com public key to communicate with your server, for which you do not have the corresponding private key. Hence you will not be able to decrypt the pre_master_secret from the client certificate message, and the ssl/tls handshake will fail.
I'm a beginner in OpenSSL tools. I don't understand some concepts. Can you explain these concepts to me?
I want to understand concepts such as CA,Self-Signed Certificate or any concept for better understanding.
(Sorry if I am using the wrong terminology or grammar, I am learning english language.)
The purpose of certificates is to assert a piece of information in a way that you can verify. Public key certificates, more specifically X.509 certificates in this context, assert the binding between a public key, identifiers (the Subject Distinguished Name and/or Subject Alternative Names) and various other attributes. Altogether, these pieces of informations are signed so as to form the certificate.
X.509 certificates have both an issuer and a subject. The subject is the identifier representing who or what that certificate identifies (and who or what owns the private key matching the public key within this certificate). The issuer represents the identifier of the person or organisation that what used their private key to sign this certificate.
Certificate usage can be broadly split into two different categories: certificates that are used for a specific application or service (e.g. authenticating an SSL/TLS server), and certificates that are used to prove the validity of other certificates.
For the latter, certificates are used as building blocks of Public Key Infrastructures (PKIs). A Certification Authority (CA) is an institution that issues certificates: it signs the assertion that binds the public key in the certificate to the subject. When doing so, it puts its own name as the issuer name in the certificate it issues.
If you compare a certificate to a passport (which binds together your picture and your name), the CA would be your passport authority: those who actually certify that what the passport says is true, for others to be able to verify it.
Trusting a CA allows you to trust the certificates it has issued. You can build a chain of trust between a CA you trust and certificates issued by this CAs which you haven't seen before.
Along with this comes a "bootstrapping" problem: how do you trust the CAs themselves?
Self-signed certificates are certificates where the issuer and the subject are identical; they are signed with the private key matching the public key they contain. They are at the top of the chain of trust. They tend to be CA certificates (unless bespoke for a particular service, which you wouldn't be able to trust without external verification).
CA certificates are certificates that can be used for issuing/validating other certificates. (They can be intermediate CA certificates if they are in the middle of the chain between a root/self-signed CA certificate and a certificate you wish to verify.) The rules defining how certificates can be used to verify other certificates are defined in the PKIX specification (RFC 3280/5280).
Browsers and operating systems come with a pre-installed list of CA certificates that you trust by default. These are mostly commercial CAs which check the information about the service in the certificate, often for a fee. In counterpart, you can trust the content of the certificates they issue (most of the time, it's not a perfect system). There is a "leap of faith" involved here, since you need to trust the browser/OS to have included only reputable CA certificates.
If you use openssl s_client and you see a message like "self-signed certificate in the chain" or "unable to verify certificate", it doesn't necessarily mean that something is wrong, but openssl doesn't use a pre-defined list of trusted CA certificates by default. Most of its command have an options like -CAfile or CApath that allow you to specify which CA certificates you are willing to trust.
Self-signed certificates for a service are a specific case, whereby the service self-asserted its content. You generally have no way of verifying the authenticity of such a certificate, unless you have an external way of trusting it (for example, if you have installed it yourself on a machine and change check its content manually, or if someone you trust gave it to you).
(You may also be interested in this question about how an HTTPS server certificate is used.)
Generally the purpose of a certificate is to establish a trust chain: "I trust this 3rd party company, they trust you, therefore I can trust you." Self-signed certificate means you generated it yourself, and therefore I'm really not gaining trust in you. (These are great for testing, but not much else.) The other type is a trusted certificate, obtained by getting a reputable company to sell you one (like Verisign). It's a commodity market, so their prices are pretty consistent between companies. It does depend on the intended use and the scope of the certificate. (e.g. a certificate for signing an Android app is very different from a certificate used for validating https://www.example.com/.)
The "CA" or Certificate Authority is the company that issued the certificate. In the case of a trusted certificate, it's that company -- e.g. Verisign. In the case of a self-signed certificate, the CA is you -- you issued the certificate.
Self-signed certificates will cause some kind of "untrusted" alert in most browsers, asking you if you want to proceed and add an exception, etc. This does not mean the connection is any less secure though -- it is still over SSL.
Generally CA's charge a fee but there are some free ones around if you search.