i will deploy a fleet of offline only deviced to the field. They will authenticate to each other with a x509 TLS certificate signed by a custom chain, which each will hold inside of a hardware crypto element.
Is there a field in a x509 certificate that is widely used for storing a device type and serial number?
The common name (CN) could be used, but is checked for a valid domain by some libraries automatically which disqualifies it in my point of view.
Adding a custom certificate extension seems to also be not ideal as some libraries might not support this, as i have read.
Is there a field that is widely supported and can be used for arbitrary userdata?
Related
ACME is used by some certificate authorities to process automated signing of certificate requests and issue resulting certificates.
An increasing number of applications (Eg Traefik) now have builtin support for ACME. This is very useful for managing certificate cycling without tracking where every deployed application stores its certificates.
However "free" certificates from letsencrypt and similar certificate authorities are not always appropriate for all applications. Such examples include some software requiring the exact same certificate being installed in multiple layers of an application's edge gateway (yes this does happen).
I'm wondering if, hypothetically, ACME v2 can be used to redistribute existing SSL certificates and associated private keys. Or is it only capable if responding to CSRs where the private key is never transferred between ACME server and client?
ACME is defined by RFC8555 currently.
There is nothing that prevents other CA to use it, besides Let's Encrypt, and indeed there are other CAs existing using it, and others adding it to their existing API.
The key associated to a certificate should never travel. The CA shouldn't know it. As such, there are no operations in ACME that would allow a CA to send the key, besides the certificate, and that is a good thing.
Retrieving a certificate is a core operation, see "7.4.2. Downloading the Certificate". It could happen separately/outside of a previous certificate request. The problem being then: how does the client know which URL to use to download a specific certificate (an information that it receives when doing the normal authorization/validation steps)?
There are other protocols to manage communication of cryptographic materials such as X509 certificates.
Still in ACME, you might be interested in RFC 8739 "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)" which allows the CA to pre-generate certificates.
And the related RFC 9115 "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates",
Outside of ACME, but very similar, you have RFC 8894 "Simple Certificate Enrolment Protocol" (but still no transmission of private key).
But you are not clearly describing the problem you have around "redistribute existing SSL(sic) certificates and associated private keys". What else do you really need besides an URL that gives back that data if it is that you want to send back to client (but again: making the private key travel is, in general, a bad idea)? Is authenticating the client the problem? Discoverability of the URL to use to download a specific certificate/key?
Is there a difference between certificates, let's say from Apple for signing or Let's Encrypt for TLS/SSL? Are they interchangeable or when generated do they have specific params that make one good for ID and one good for encryption?
Depending on what you mean, they're either exactly the same, or they're different. (Isn't language grand?)
A code-signing certificate and a TLS server certificate and a TLS client certificate are all X.509 Public Key Certificates, described by IETF RFC 5280 and ITU-T X.509 (whence the name).
Within the certificate there's a(n optional) set of extensions (the well-defined ones were extending the rigid structure of the previous data versions). One of these extensions is called Extended Key Usage (which, confusingly, is described by X509EnhancedKeyUsageExtension in .NET), generally abbreviated as EKU. The EKU extension is just a list of identifiers that indicate to what purposes the certificate is valid. (Organizations like the CA/Browser Forum come up with rules for what a CA has to do before allowing each specific type of purpose to be claimed.)
The current certificate I see for stackoverflow.com has two listed purposes: 1.3.6.1.5.5.7.3.1 and 1.3.6.1.5.5.7.3.2. Those identifiers don't mean much to the general population, though, so many systems will replace them with friendlier names. Firefox 89's description is "Server Authentication, Client Authentication".
TLS/SSL have a lax approach to EKU: If the certificate has an EKU extension then the TLS Server (1.3.6.1.5.5.7.3.1) or TLS Client (1.3.6.1.5.5.7.3.2) purpose must be present (the correct one for the role it's taking), but if the EKU extension isn't present then the certificate is acceptable.
RFC 3161 Timestamping is less lax. It requires that the certificate have an EKU extension (and only one of them, which can contain multiple purpose values) which contains the purpose 1.3.6.1.5.5.7.3.8, in section 2.3.
So, the differences are just in EKU values.
TLS Server: 1.3.6.1.5.5.7.3.1
TLS Client: 1.3.6.1.5.5.7.3.2
Code Signing: 1.3.6.1.5.5.7.3.3
Timestamping: 1.3.6.1.5.5.7.3.8
There are a lot of others in general use, like 1.3.6.1.4.1.311.10.3.5 (Microsoft Windows Hardware Quality Labs Driver Verification), they don't all start with "1.3.6.1.5.5.7.3." (though a good number of the common ones do).
The question may sound a bit stupid but I really want to know this.
When we download a file, say abc.exe, it is digitally signed with some digital certificate of some organisation. Why do we need to install that certificate? What is the use of it? What if we dont install it?
When I run certmgr.msc in my windows system, I see some certificates already installed. What do they mean?
If you get signed material, you may want to verify the signature.
Digital signatures usually are created using a private key and can be verified using the associated public key.
Certificates essentially are transport containers for public keys with some extra information. Thus, to verify signatures you usually need the certificate of the signer.
You install certificates to make them known to your system (to allow for signature verification) and to tell your system to trust material signed by the associated private key.
As having to install certificates by each and every party you want to trust is too much work, certificates can have hierarchies, some root certificate may be the issuer of multiple other certificates, and by trusting that root you implicitly trust those other certificates the root issued.
For more details you may want to ask on https://security.stackexchange.com/.
The RSA algorithm used for encryption is used for digital signatures.
Use of RSA for a signature is as under:
1. First, a message digest is calculated.
2. The private key is used to sign the digest of the message.
3. The signature is appended to the message and transmitted to the recipient.
4. The recipient calculates the digest of the received message.
5. Then, verifying the signature requires extracting the signature from the message
and using RSA on the signature with the public key.
6. If the result of the transformation and the newly calculated digest are equal, the signature is valid.
I have a small question about GPG certificates and certificates authorities.
I am using GnuPG to sign a tarball that I am hosting on my server. I would like that users who wants to download this tarball to be able to encrypt it using my public key.
At the moment, I'm storing my public key on another server that I own. There are 2 issues with this:
The key isn't "trusted", and the user get a warning
In the same idea, because the key isn't trusted, if the key is maliciously changed, the user won't see anything
I've read a bit about cryptography solutions in the past, and know a little bit how X.509 CA work, but I don't really understand how it is for PGP keys. I've tried to use my SSL (trusted) certificate in GPG, but it always fails (maybe there is an option I haven't found?).
If it's not possible to use my SSL certificate, how can I "register" my PGP certificate to a CA?
Thanks!
Best,
Thibault.
For all practical purposes, X.509 certificates and OpenPGP key pairs live in separate worlds. X.509 certificates are trusted hierarchically (building certificate chains) and OpenPGP keys are trusted on peer-to-peer basis.
As the technologies are incompatible, they are not easily replaceable by each other. To let users trust your OpenPGP key, you can publish it in one of OpenPPG key repositories (keyservers), and hope (or suggest) that users do use it as a trusted source of OpenPGP keys.
Alternatively, you can use your server's certificate to create a detached PKCS#7/CMS signature of the archive you distribute, but unlike OpenPGP there are no widespread tools available to check PKCS#7/CMS signatures on end-user computers. (Well, maybe OpenSSL will work for your user audience.) Note that KeyUsage of the server's certificate probably won't be appropriate for signing, so the users will get a warning.
Please note that OpenPGP keys are called "keys", and X.509 certificates are called in this way too. There exist no "pgp certificates" as well as no "ssl certificates".
We want to add automatic software updates to our application, but our company isn't yet ready to buy a code-signing certificate from a trusted root CA, so we'll be using a self-signed certificate to sign code updates (.exe and .dll) for now.
Question: how to verify a binary signed with a self-signed certificate, without having to install the certificate, using Microsoft's Cryptography API? The .cer file to check against will be bundled with the application. Or is it simpler to use a generic Crypto library?
You can skip the whole X509 thing, after all you don't really need it if you're going to be using your own certificates...
For what you want to do, first you have to generate your RSA private/public key pair. Then you store the public key in your application.
When you have an update, you sign it on your site, by getting the MD5 or SHA-1 or whatever hash you want to use; then you encrypt that hash with the private key. The installed applications fetch the update and the signature (the encrypted hash); when the application gets the binary file, it computes its hash, then decrypts the other one using the public key and compares them. If they're identical then it's a valid update, otherwise you reject it and warn the user or something.
With X509 certificates that are self-signed the mechanism is going to be exactly that, but the public key is going to have a bunch of additional data like the identity of the issuer which will be the same identity of the certificate.
I seem to recall hearing of a way to enable self-signed certs some years ago, back in the Win2k days, but it was very hacky, not at all suitable for public deployment and has probably been "fixed". If you do think about using some other crypto library, or developing your own, take care: it's very hard to distinguish good crypto from bad crypto.