Q1: Is there a way to add custom extention attributes (e.g. CertificatePolicies, ExtemdedKeyUsage, KeyUsage, Admission,...) to an CSR generated with bouncyCastle 1.5.1?
Q2: Will a CA take extention attributes into account at all?
Q1: See Adding attributes to certificate request, java + bouncycastle 1.48
Q2: This may depend on the CA, but I think the answer is usually "no". Certainly no CA will just copy CertificatePolicies, KeyUsage or ExtendedKeyUsage from your CSR to the certificate, as that would be horribly insecure.
Related
I'm currently trying to use a CA Bundle with NodeJS 14.0. I've been using Namecheap's article as a guide the implement this feature. I'm currently stuck on a few things:
For the ca parameter for https.createServer(), what file formats are allowed to be passed in?
How do I check that a CA bundle is actually being used?
For the ca parameter for https.createServer(), what file formats are allowed to be passed in?
From NodeJS tls.createSecureContext:
Any string or Buffer can contain multiple PEM CAs concatenated together
Though, in general NodeJS uses PEM format.
How do I check that a CA bundle is actually being used?
You can use a certificate not signed by your CA, e.g. a self-signed certificate.
One point, possibly more subtle than you wanted: nodejs tls.createSecureContext internally calls OpenSSL PEM_read_bio_X509_AUX which actually accepts three PEM formats (or any sequence of those three formats, since nodejs loops). For two of them the base64/64cpl blob contains (exactly) an X.509 certificate, as respecified in rfc7468 sec 5, with either preferred label "CERTIFICATE" or deprecated label "X509 CERTIFICATE". In addition OpenSSL accepts a format of its own with label "TRUSTED CERTIFICATE" where the blob contains an X.509 certificate plus additional (ASN.1) data defined by OpenSSL; see e.g. the man page for d2i_X509_AUX online here. OpenSSL doesn't use this additional data for much, and of course nothing else uses it at all, so it's rare.
And to avoid confusion it might be worth noting that all OpenSSL PEM_read_ routines, including this one, skip any 'comment' data while searching for the PEM data, so actually a file/buffer that contains garbage, then a PEM cert, then more garbage, then another PEM cert, etc. will work the same as if it contained only the PEM certs.
Looking at LetsEncrypt FAQ page, they have clearly stated that email encryption and code signing require a different type of certificate and therefore they are not supported by LetsEncrypt.
My understanding is that https and S/MIME both require X.509 certificates. What is the difference between certificates these two technologies require?
Among other things (like the encryption key), an X.509 certificate also specifies what it may be used for. X.509 certificates for HTTPS and S/MIME usage basically have different usages.
The structure of an X.509 certificate is fairly complex. Its possible usage depends on attributes and extensions within the certificate, and require that specific combinations of them with specific values must be present.
For example, an S/MIME certificate, requires a Key Usage attribute with something like Encrypt, Verify, Wrap, Derive, a Key Usage extension that must have the Critical attribute set to Yes and include a Usage attribute with Key Encipherment plus in the Extended Key Usage extension (sic!) it should list the Purpose attribute value Email Protection.
Note that Key Usage extension Data Encipherment is not required, because in S/MIME, the data contents are encrypted by a random symmetric key which then is encrypted with the private key from the certificate. This is called hybrid encryption and it is done for performance and scalability reasons.
The certificate requirements even extend into the certificate chain, meaning that the certificate must be signed by another certificate that has been issued to sign certificates for that usage.
Note that the above example may not be 100% correct, because the subject is so complex, and I don't fully understand every aspect of it myself. I found this quote which I think describes the situation fairly well:
I think a lot of purists would rather have PKI be useless to anyone in
any practical terms than to have it made simple enough to use, but
potentially "flawed". — Chris Zimman
Resources that helped me:
X.509 Style Guide by Peter Gutmann: an attempt to shed light on the relations of attributes and extensions and their interpretations
RFC 4262 - X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities
I currently believe cacert.pem is a bunch of keys that I can use to check that the site I'm talking to is in fact the site its claiming to be. As such, if I sent someone a program that was dependent on cacert.pem I can just send them a version on my computer and this has no security threat to me.
The only security threat would be for them and that is if I sent them a phony cacert.pem.
Is this correct and am I safe sending the version of cacert.pem on my computer to another potentially untrusted person?
EDIT:
AS Steffen pointed out, cacert.pem could refer to any file. I was referring to in particular the one that is found in the Requests Python package.
I don't know which cacert.pem file you are talking about, but/etc/ssl/cacert.pem on BSD or the /etc/ssl/certs folder on Linux contain just a public list of trusted certificate agencies, which are used to verify trust for SSL connections. There is no secret in these files and usually they are not even system specific (although one might add or remove CAs to manage own trust settings).
But again, I don't know what your cacert.pem file contains, because there is no inherent semantic with this file name. If it contains also private keys you should definitely not give it to others.
The only security threat would be for them and that is if I sent them a phony cacert.pem.
cacert.pem is a collection of Root CAs and Subordinate CAs used to certify a site or service.
The three threats here are:
You add your own CA, and then later MitM the connection
The wrong CA certifies the site or service, and an attacker then later MitM the connection
Your copy of cacert.pem is tampered in transit
(1) is less of a concern because it would require you to have a privileged network position, like on the same LAN or in the telecom infrastructure. You could add your own CA and the recipient would likely be no wiser.
(2) is a real problem. For example, we know Google is certified by Equifax Secure Certificate Authority. Equifax certifies a Subordinate CA called GeoTrust Global CA. And GeoTrust certifies a Google Subordinate CA called Google Internet Authority G2.
So the first problem with (2) is Diginotar and recently MSC Holdings claimed to certify Google properties, which we know is wrong. They could pull it off because of the collection of Roots and Subordinates.
The second problem with (2) is related to the first. Because you trust, say, Google Internet Authority G2, Google can mint certificates for any domain, and not just their properties. The problem here is its an unconstrained Subordinate CA, and it was done because it was too inconvenient.
(3) is simply an attack by a MitM. He can remove a needed certificate, which could result in a DoS. Or he could insert a CA, which leads back to (1). or he could corrupt the whole file.
My company have code singing cert from Thawte to sing Windows applications. I need to sing my j2me jar file with this cert. I've used openssl to convert to pkcs12 format using this guide:
http://conshell.net/wiki/index.php/OpenSSL_to_Keytool_Conversion_tips
but I have one problem - I can't add full chain of certs. Just one, no intermediate and crossroot.
So when I signing there's only MIDlet-Certificate-1-1 param. No MIDlet-Certificate-1-2 and MIDlet-Certificate-1-3.
Is it possible to create a chain in keystore somehow?
At first you need another type of certificate - Sun Java certificate.
I don't exactly remember signing process but there are tutorials on this subject. Just try to google "midlet signing tutorial". Or read, for example, this one: http://www.forum.nokia.com/piazza/wiki/images/7/7e/MIDP_2_0_Tutorial_On_Signed_MIDlets_v1_1_en.pdf?20080603115110
The man page did not clearly specify this. But looking at openssl's apps implementations, SSL_CTX_use_PrivateKey* calls are usually made after SSL_CTX_use_certificate_file succeeded. I assume this is mostly used at the server side.
I recently confused the above function with SSL_CTX_load_verify_locations wherein you could specify a CA certificate file and path. It turned out that SSL_CTX_load_verify_locations is the one I needed to verify a server certificate which is signed by a Trusted Authority.
SSL_CTX_use_certificate_file() is used to load the certificates into the CTX object either in PEM or DER format. The certificates can be chained ultimately ending at the root certificates. SSL_CTX_use_certificate_file API loads the first certificate into the CTX context;not the entire chain of certificates. If you prefer that thorough check of certificates is needed then you need to opt for SSL_CTX_use_certificate_chain_file()
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.ibm.ztpf-ztpfdf.doc_put.cur/gtpc2/cpp_ssl_ctx_use_certificate_file.html