through the bouncycastle wiki page I was able to understand how to create a X.509 root certificate and a certification request, but I do not quite understand how to proceed concept- and programming wise after that.
Lets assume party A does a cert request and gets his client certificate from the CA. How can some party B validate A's certificate? What kind of certificate does A need? A root certificate? A 'normal' client certificate?
And how does the validation work on programming level, if we assume that A has successfully send his certificate in DER or PEM format to B?
Any help is much appreciated.
Best Regards,
Rob
From a programmer's perspective, you need a few things to validate an X.509 certificate.
A set of "trust anchors"—the root certificates of CAs that you rely on. These should be protected from tampering, so that an attacker doesn't replace a CA certificate with his own fake. The public keys in these certificates are used to verify the digital signatures on other certificates.
A collection of Intermediate certificates. The application might keep a collection of these, but most protocols, like SSL and S/MIME, that use certificates have a standard way to provide extra certificates. Storing these doesn't require any special care; their integrity is protected by the signature of a root CA.
Revocation information. Even if a certificate was issued by a CA, it might have been revoked prematurely because the private key was disclosed, or the end entity changed their identity. (For example, a person switches jobs and a certificate with their old company's name in it is revoked.) CRLs or a web-service like OCSP can be used to get an update about the status of a certificate.
With these inputs available, you can use the built-in PKIX support to construct and validate a certificate path.
/* Givens. */
InputStream trustStoreInput = ...
char[] password = ...
List<X509Certificate> chain = ...
Collection<X509CRL> crls = ...
/* Construct a valid path. */
KeyStore anchors = KeyStore.getInstance(KeyStore.getDefaultType());
anchors.load(trustStoreInput, password);
X509CertSelector target = new X509CertSelector();
target.setCertificate(chain.get(0));
PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, target);
CertStoreParameters intermediates = new CollectionCertStoreParameters(chain)
params.addCertStore(CertStore.getInstance("Collection", intermediates));
CertStoreParameters revoked = new CollectionCertStoreParameters(crls);
params.addCertStore(CertStore.getInstance("Collection", revoked));
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
/*
* If build() returns successfully, the certificate is valid. More details
* about the valid path can be obtained through the PKIXBuilderResult.
* If no valid path can be found, a CertPathBuilderException is thrown.
*/
PKIXBuilderResult r = (PKIXBuilderResult) builder.build(params);
An important thing to note is that if a path cannot be found, you don't get much information about the reason. This can be frustrating, but it is that way by design. In general, there are many potential paths. If they all fail for different reasons, how would the path builder decide what to report as the reason?
Ok, the idea behind CAs is as follows:
CAs are people everyone trusts. To this end, a selection of Trusted CAs is available in your browser/email client/even on my mobile. In your case, your public root key (certificate) should be in your application.
Users send requests to the CA for a certificate in PEM format with the public key. CAs do some (I leave this ambiguous deliberately) form of verification of the end user, such as charging them money or in the case of enhanced verification (green) certs, background checks.
If the CA doesn't think the user's request is valid, they communicate this somehow.
If they do, they sign the public key and produce a certificate containing this information. This is where you process the cert-req and turn it into an X.509 cert.
Other users come across our fictitious user and want to know if they can trust them. So, they take a look at the certificate and find it is digitally signed by someone they have in their trust list. So, the fact that they trust the root CA and only the root CA could sign (via their private key) this user's public key and the CA trusts the user, we deduce that the new user can trust mr fictitious.
On a programmatic level, you implement this by reading the X.509 certificate and working out who the CA is supposed to be. Given that CA's fingerprint, you find it in your database and verify the signature. If it matches, you have your chain of trust.
This works because, as I've said, only the CA can create the digital signature but anyone can verify it. It is exactly the reverse of the encryption concept. What you do is "encrypt with the private key" the data you wish to sign and verify that the "decrypt with the public key" equals the data you've got.
Related
I have a document that is digitally signed using CAdES. I use BouncyCastle APIs to get the X509Certificate[] instances of the signers, but let's assume the list contains one and one only element.
I need to verify whether this certificate is trusted or not at today's date, and I don't want to use the system's standard trust store which is normally used to trust SSL certificates. No, I want to build my own trust list with a list of .cer files in my classpath. At the moment, a single CA is trusted but obviously in the future a few more certificates may be added.
So far I have read this and tried to implement in my code. I need no SSLContext, I need to check the validity of a digitally signed document. I am now confused.
X509TrustManager APIs do however provide only methods for validating client/server certificates, but mine only have digital signature/non-repudiation usage flags.
The questions can be formulated in two ways that lead to the same:
How does one in Java check the validity of an X509Certificate instance against a custom root CA list that can be loaded in memory?
How does one check that a digitally-signed document is signed with a certificate deriving from a known CA of a custom list?
Extract from the CAdES signature for each signer the signer's certificate and also the intermediate certificates as a X509Certificate list. Build also a set with all root CA certificates
Then you can use this (slightly adapted) example code to verify and build the certification chain using Java and BouncyCastle. It will return the certification chain if verification is successful
public PKIXCertPathBuilderResult verifyCertificateChain(
X509Certificate cert,
Set<X509Certificate> trustedRootCerts,
Set<X509Certificate> intermediateCerts) throws GeneralSecurityException {
// Create the selector that specifies the starting certificate
X509CertSelector selector = new X509CertSelector();
selector.setCertificate(cert);
// Create the trust anchors (set of root CA certificates)
Set<TrustAnchor> trustAnchors = new HashSet<TrustAnchor>();
for (X509Certificate trustedRootCert : trustedRootCerts) {
trustAnchors.add(new TrustAnchor(trustedRootCert, null));
}
// Configure the PKIX certificate builder algorithm parameters
PKIXBuilderParameters pkixParams =
new PKIXBuilderParameters(trustAnchors, selector);
// Disable CRL checks (this is done manually as additional step)
pkixParams.setRevocationEnabled(false);
// Specify a list of intermediate certificates
// certificate itself has to be added to the list
intermediateCerts.add(cert);
CertStore intermediateCertStore = CertStore.getInstance("Collection",
new CollectionCertStoreParameters(intermediateCerts), "BC");
pkixParams.addCertStore(intermediateCertStore);
// Build and verify the certification chain
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX", "BC");
PKIXCertPathBuilderResult result =
(PKIXCertPathBuilderResult) builder.build(pkixParams);
return result;
}
If you do not want to deal with CAdES complexity, I suggest to use SD-DSS open-source project
I have initiated an HTTPS connection using something like
httpsCert.connect();
where httpsCert is HttpsURLConnection httpsCert.
Now I do something like Certificate[] certs = httpsCert.getServerCertificates(); to retrieve the server x.509 certificates.
I want to retrieve which root CA or the intermediary CA signed the certificate received above.
My approach has been to look at the issuer field in the certificate received above, but is it a good approach. I mean is there a better approach of doing this ?
Secondly, from developer.android.com/HttpsUrlConnection, it appears that getServerCertificates () would return the list of certificates identifying the peer with the peer's identity certificate followed by CAs. In this context, in case of some certificates, like certificates fetched by Google apps, there is a section of the certificate that says Authority Information Access:
CA Issuers - URI:http://pki.google.com/GIAG2.crt however this is not the case with other apps fetching certificates signed by other authorities.
Second question is how does Android validate the certificate path for certificates signed by intermediary CAs ?
I want to retrieve which root CA or the intermediary CA signed the certificate received above.
If you are talking about missing certificates, then you can't. This is a well known problem in PKI called the "which directory" problem. The problem is you don't know where to look to find the missing certificates. The problem is resolved by the server sending all the certificates you need to build the chain to perform the validation.
You still have to root trust somewhere; otherwise the bad guy would send you the chain he wants you to trust and you would be no wiser. That's why user agents like browsers and cURL carry around a list like cacert.pem.
In fact, some poorly configured servers will not send the needed intermediate certificates. In this case, the browsers carry around a list of intermediates to fill in the missing pieces.
Also see Peter Gutmann's Engineering Security.
My approach has been to look at the issuer field in the certificate received above, but is it a good approach. I mean is there a better approach of doing this ?
That's roughly how the chain is built. When you use the issuer's name, you are using a Distinguished Name (Issuer DN in "directory speak"). There's a Subject DN, too. The Issuer is the authority, and the subject is the entity that its issued to.
When validating a chain, its called "path building". That leads you to RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building.
The DN alone is usually not enough because a bad guy can re-use the same name and you would be no wiser. So you often use the Authority Key Identifier (AKI in "directory speak"), which is a thumbprint or digest of the the issuer's public key. The bad guy cannot do useful things by forging the AKI because he does not have the private key to go along with it.
Other things used to make the tuple unique is the Serial Number. This is important when a CA re-issues a certificate using the same DN and same public key - only the serial number differs. You will see this happen when the hash is changed from SHA-1 to SHA-256.
Re-issuing and changing only the hash has happened in the past. Its one of the more difficult path validation failures to track down because everything looks OK on the surface. It takes you a while to realize the DN and AKI are OK, but the SN does not match.
Second question is how does Android validate the certificate path for certificates signed by intermediary CAs ?
Android is Java, and Java follows the RFCs. Here are the three RFCs you need to consult. Its not a small topic, and you could write a book providing the full treatment:
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building
The "Internet X.509 Public Key Infrastructure" is also referred to as PKIX. Its the Internet's PKI profile. Other organization's PKI's can and sometimes will be a different. That just means other organizations may have different rules than what PKIX uses and documents in the RFCs.
Note well: a "CA root" will be self-signed. The Subject DN will be the same as the Issuer DN, the Subject's Key Identifier (SKI in "directory speak") will be the issuer's Authority Key Identifier (AKI in "directory speak"), etc. In addition, basic constraints will have CA=true and it will probably be marked critical.
An intermediate CA certificate will be issued against (or chained to) a distinct certificate, so Subject DN will not be the same as Issuer DN. But like the self-signed root, basic constraints will have CA=true and it will probably be marked critical.
Its perfectly acceptable for you - as a relying party - to trust an intermediate but not a root, even if the intermediate was certified by the root. That's your prerogative.
Authority Information Access: CA Issuers is stored in CA Extensions.
This code prints the list of urls from Authority Information Access Extension. Thats what you need.
import sun.security.util.ObjectIdentifier;
import sun.security.x509.X509CertImpl;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
class readCert{
public boolean isExtAuthorityInfoAccess(Extension ext){
Pattern re = Pattern.compile("\\bcaIssuers\\b",Pattern.CASE_INSENSITIVE);
Matcher m = re.matcher(ext.toString());
if (m.find()) {
return true;
} else {
return false;
}
};
public static List<String> getAuthorityInfoAccesssUrls(String text)
{
List<String> containedUrls = new ArrayList<String>();
Pattern pattern = Pattern.compile(
"(?:^|[\\W])((ht|f)tp(s?):\\/\\/|www\\.)"
+ "(([\\w\\-]+\\.){1,}?([\\w\\-.~]+\\/?)*"
+ "[\\p{Alnum}.,%_=?&#\\-+()\\[\\]\\*$~#!:/{};']*)",
Pattern.CASE_INSENSITIVE | Pattern.MULTILINE | Pattern.DOTALL);
Matcher urlMatcher = pattern.matcher(text);
while (urlMatcher.find())
{
containedUrls.add(text.substring(urlMatcher.start(0),
urlMatcher.end(0)));
}
return containedUrls;
};
public static void main(String[] args) {
readCert rc = new readCert();
try {
File file = new File("yourcert.crt");
byte[] encCert = new byte[(int) file.length()];
FileInputStream fis = new FileInputStream(file);
fis.read(encCert);
fis.close();
InputStream in = new ByteArrayInputStream(encCert);
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate)certFactory.generateCertificate(in);
X509CertImpl impl = (X509CertImpl)cert;
int extnum = 0;
if (cert.getNonCriticalExtensionOIDs() != null) {
for (String extOID : cert.getNonCriticalExtensionOIDs()) {
Extension ext = impl.getExtension(new ObjectIdentifier(extOID));
if (ext != null) {
if (rc.isExtAuthorityInfoAccess(ext)) {
System.out.println(rc.getAuthorityInfoAccesssUrls(ext.toString()));
// System.out.println("#"+(++extnum)+": "+ ext.toString());
// CA ISSUERS ARE HERE
}
}
}
}
} catch ( Exception e) {
e.printStackTrace();
};
}
}
I have a chain of certificates (X509Certificate []), but I have only one certificate in the chain. I need to get the complete chain.
I have tried the openssl command, but that is not useful here. Can someone please tell me how to:
Convert this X509Certificate to PEM or ASN.1/DER that I can save in my file storage?
Get the complete chain using this certificate?
Edit:
So, code-wise what I'm trying to achieve is something like:
protected static String convertToPem(X509Certificate cert) {
Base64 encoder = new Base64(64);
String cert_begin = "-----BEGIN CERTIFICATE-----\n";
String end_cert = "-----END CERTIFICATE-----";
byte[] derCert = cert.getEncoded();
String pemCertPre = new String(Base64.encodeBase64(derCert));
String pemCert = cert_begin + pemCertPre + end_cert;
return pemCert;
}
But, this is not working. Basically, I'm looking for a method that takes a X509Certificate object and then converts it to a .pem etc, that is saved on the device.
Convert this X509Certificate object to .cer/ .per/ .der that I can save in my file storage?
See, for example, the answer at OpenSSL's rsautl cannot load public key created with PEM_write_RSAPublicKey. It tells you how to convert keys to/from PEM and ASN.1/DER format, and includes a treatment of Traditional Format (a.k.a. SubjectPublicKeyInfo).
If you are not doing it programmatically, then you should search for the answer. There are plenty of off-topic question on how to use the openssl command to convert between ASN.1/DER and PEM. Or ask on Super User, where they specialize in commands and their use.
Get the complete chain using this certificate?
This is a well known problem in PKI called the Which Directory problem. The solution is to have the server or service provide the missing intermediate CA certificates. If you can't validate a web server or service's identity because you are missing intermediate CA certificates, then the server is misconfigured.
Once you have the intermediate CA certificates, you still have to root trust somewhere. You can use the self-signed CA, or one of the intermediates signed by the self-signed CA.
This answer is helpful in troubleshooting a misconfugred server using OpenSSL's s_client: SSL site and browser warning.
Related: if there was a global directory of certificates like the ITU envisioned in X.500, then you would not have the second problem. A relying party or user agent would just fetch the certificate it needed from the directory.
But we lack a central directory, so relying parties and user agents often use the CA Zoo (a.k.a., the local Trust Store or cacerts.pem). This has its own set of problems, like the wrong CA certifying a site or service.
One of the off-shoots is the CA Cartel, where browser are in partnership with the CAs at the CA/Browser Forum. Browser have requirements for inclusion, but they often can't punish a misbehaving CA like Trustwave.
And the browsers have managed to box themselves into a position where the Internet of Things (IoT) will not work because of the browser's reliance/requirements on server certificates signed by a CA.
I'm required to create a program that validate any given X509 Certificate Version3 if it is trusted or not by verifying the signature. In order to to do that, I need to be able to know the issuer's public key who has signed that given certificate. I know how to output the issuer information using getIssuerDN() method but what I don't know is how to get the issuer's public key when I only know its name !
The only solution I have so far is to maintain a list of public keys for the most common Certificate Authorities on the web, and just search through it. Although this solution is doable, it seems impractical to me.
Therefore, is there another idea to get the Issuer's public key from a certificate directly and then complete the process of verification ?
Here is my code for getting the Issuer's name but NOT its public key.
URL url = new URL("https link here!");
HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
con.connect();
Certificate cert[] = con.getServerCertificates();
X509Certificate x509cert = (X509Certificate) cert[0];
String[] st= x509cert.getIssuerDN().toString().split(",");
System.out.println("Issuer CN is: "+st[0].toString());
I'm required to create a program that validate any given X509 Certificate Version3 if it is trusted or not by verifying the signature. In order to to do that, I need to be able to know the issuer's public key who has signed that given certificate.
No. Either you or whoever gave you the assignment doesn't understand PKI. The idea is that you already trust some issuers by virtue of already having their certificates, e.g. in the cacerts file distributed with the JRE, and therefore their public keys. If the certificate you're asked to verify is traceable to one of these issuers and it passes all other verifications, you can trust it. Mere verification via the public key alone is not sufficient.
I want to read issuer String from user's public key with Bouncy Castle. Is there example code or something from which I can learn?
If you can obtain the certificate object, then you can do the following:
((X509Certificate) certificate).getIssuerX500Principal().getName();
The public key itself does not have an issuer - only a certificate has. And you can get the public key from the certificate, but not vice-versa.
Update: Since it appears that you want to verify the validity of your users, the public key alone does not provide this info. Public keys are used for encryption / digital signature verification, but for the rest of PKI you need the certificate. Actually, verifying the issuer that is written in the certificate gives you no guarantee whatsoever. You need to check:
the certificate revocation lists - i.e. whether the certificate is not revoked. This is done either via the provided CRLs or via the ocsp protocol.
the expiration of the certificate
The public key object doesn't say who generated it. It just contains what you need to encrypt (or verify) with the public key.
If you got the public key from a certificate (java.security.cert.X509Certificate), then you can get the certificate issuer from that by using getIssuerX500Principal().
The certificate is a binding of an identity to a public key. As part of that, the certificate indicates who it was issued by. So you can verify whether you trust that issuer and, therefore, the binding.
Also, the key pair very likely wasn't generated by the certificate issuer. The subject just proved to the issuer that it did possess the associated private key.