I see the term "x509 profile" being used in a technical document on PKI that I am reading, but no explanation is given. I googled for what a "x509 profile" means but the results were not helpful. For example the wikipedia entry on x509 contains phrases like:
IPSec can use the RFC 4945 profile for authenticating peers.
The OpenCable security specification defines its own profile of X.509 for use in the cable industry.
And no where is the definition of a profile given. It seems it is assumed that the meaning of a profile is a given!
What exactly is a profile in x509 context? I know, from the word I can imagine it means some form classifications of x509, but the question is: what makes up this classification? What characteristics of an x509 are used to form these classifications/profiles? Where can one view all available classifications?
A minimal certificate consists of a Name and a Public Key. The CA which signs this certificate asserts that the entity named owns the private key which matches this Public Key.
In addition to this, a certificate can (and more often than not, must) contain additional information. Examples are Issuer and Version fields, and Key Usage, Enhanced Key Usage and Subject Alternate Name extensions.
A certificate profile is a definition of the additional information. For example, section 5.1.3.2 Key Usage of RFC 4945 says:
A summary of the logic flow for peer cert validation follows:
If no KU extension, continue.
If KU present and doesn't mention digitalSignature or nonRepudiation (both, in addition to other KUs, is also fine), reject cert.
Section 5.1.3.6 goes on to describe the Subject Alternate Name expected for IPSec certificates.
Basically, the profile is a definition of how a certificate is expected to be generated for a certain use-case.
You can define your own certificate profiles, but you'd need to have a very good reason to do so. Most use-cases have been covered by existing profiles, so you may end up re-inventing the wheel.
RFC 5280 defines a profiles for X.509 certificates and CRLs for use on the Internet. It lists what is expected of a certificate by services operating on the Internet (as opposed to other networks such as X.25). The fields are fixed (section 4.1) and it also defines standard extensions. In addition to those, you can also define your own extensions. However, you'd need CAs that can create those certificates and clients that understand what to do with them.
Related
I've read the I-TEXT digital signature e-text, and also previous posts answered by MKL (who seems to be the authority along with Bruno on this topic).
essentially I have an Azure app service that gets the digital sig (base 64) and certificate chain from the company's signing API. The company's signing API returns a signature in Base64 along with a certificate chain.
I just want the to insert a signature object/container into the pdf so it will show in the signature panel when an end user opens up the pdf. I prefer to use deferred signing.
I've shifted from chapter 4's "clientseversigning example" to instead Deferred Signing in MKL's "How to create a PDF signature without knowing the signer certificate early".
The Company API returns a "plain" signature, that I am pretty sure, and also returns a chain of 3 string certificates.
I should note I do have the root and sub certs in advance (2 .cer files) but I am not using them in "prepping" the pdf for hashing right now since the deferred signing example doesn't make use of them obviously. For the container construction code (after getting the response from the Company API), I use the 3 certs chain returned from the company API, but I also tried it with the 2 .cer files, to no avail.
The only difference between my code and the one in the example is instead of byte[] certificateBytes = THE_RETRIEVED_CERTIFICATE_BYTES; X509Certificate x509Certificate = new X509CertificateParser().ReadCertificate(certificateBytes); I build 3 x509Certificates (one for each string in the chain returned from the Company API.
Sadly things wont work, I get these errors in Acrobat: Signature is invalid, There are errors in the formatting or information contained in this signature, signature's identity has not yet been verified, signing time is from the clock on the signer's computer...also if I click Certificate details just below of this error in Acrobat it is blank. This was pretty much the errors I was getting when trying the "clientserversigning example"
I am trying really hard and wondering what it could be... should I try modifying the estimated size from 12000 and bump it up? or the errors I am getting in Acrobat, maybe they are hinting the certificate chain from the Company API is not being picked up by the signing deferral container construction code ... I am struggling but any tips would be so greatly appreciated
Evan
Just to clarify, I am following chapter 4's clientserversigningexample but I am getting the following once my pdf is recreated with the signature from the company API
Its saying 1) there are errors in the formatting of information
2) signer's identity has not been verified
3) signing time is from the clock on the signer's computer
now as far as "prepping" the pdf before hashing it to send for signing...I don't see anything in the ClientSigning example that specifically preps it, can I assume the IText library is prepping it under the hood?
In your question and in your comments to it you appear to be in particular interested in
whether or not one can use a signature API that returns the certificates only together with the signature, and
when to to deferred signing.
Can You Use a Signature API That Provides the User Certificate Only After Signing
To answer this one first has to clarify what kind of signatures the signature API in question creates, plain signature values (e.g. PKCS#1 RSA signatures) or full-fledged CMS signature containers.
If it creates full-fledged CMS signature containers, you can create signatures following arbitrary signature profiles as long as the signature containers follow the requirements for them (which they often do). They only restriction you have is that you cannot have information from the signer certificate in the signature visualization because that visualization is defined in the signed data of the PDF.
If it only creates plain signature values, the best you can do is create and embed simple CMS containers that don't contain pointers to the signer certificate in the signed attributes (if they have any signed attributes as all to start with). Many signature policies of interest do require such pointers, but at least Adobe Reader accepts signatures without.
If you are in this situation and want to try creating signatures with such simple signature containers, you may want to use the code from this answer, section "How to create a PDF signature without knowing the signer certificate early".
When to Use Deferred Signing
The difference between deferred signing and other iText signing calls is not that deferred signing requires less information (compared to ExternalContainer signing).
In contrast to the other iText signing methods, signDeferred re-uses the outermost existing, filled signature field of the PDF to sign and merely replaces the signature container therein.
The method name is derived from the most common use case it’s used for:
In a first step a signature field is (probably first created and then) filled using signExternalContainer with an IExternalSignatureContainer implementation that calculates the document hash to be signed but does not return the final CMS container yet, merely some (usually) empty array. The generated PDF with a filled signature field (albeit without the final signature container) is then temporarily stored (in the file system or a database).
In a second step a signature container for the determined document hash is requested and (probably asynchronously) awaited.
In a final step signDeferred is used to inject the retrieved signature container into the PDF prepared in the first step.
This deferred signing process usually is preferred in setups in which the second step, the signature container creation and retrieval, can take longer than one wants to keep the resources blocked which are required for the document in signing. This includes in particular signatures generated by remote servers or clients, especially if that signing process awaits some third party clearance or activation.
I am currently working on a project that deals with sensitivity customer data, and we are being recommended to use Digital Signatures as appose to Electronic Signatures due to its new scale and the sensitive nature of the customers' data.
I personally don't know what the legal issues are with Digital Signatures, but I know that sometimes a Certificate Authority are needed?
This program is being written in C# visual studios if that matters, but I don't really know where to start with this process. I know it works like a public and private key encryption , a Public Key Infrastructure, but I have been informed that you must "buy" a certification from a Certificate authority. You could also create your own?
I was also informed that I need to make sure this would also allow documents created by our program to be legally binding in the USA. That certain laws and procedures are different in different countries so I need to make sure these are in order before I even start coding.
I'm sorry if this sounds more like a legal question then a coding question. My searches aren't helping and I can't start coding until I know what I can and can't do.
SSL encrypts the data channel. It can be broken by the NSA and perhaps others but it is considered quite hard to do so.
I certainly think it is a reasonable and appropriate level of data security for many uses, but that is merely my personal opinion.
Digital Signatures do not encrypt your data. Digital signatures sign your data, assuring you and the recipients that the data was not changed en route, and giving you confidence that you know who signed the data.
You can use a digital certificate purchased from a certificate authority to sign data. Or you can create a self-signed key for your organization and then use subordinate signer keys. We have many many customers who do this.
Documents signed with digital signatures are legally binding everywhere in the world. In some jurisdictions, for some purposes, you need a qualified digital signature. That means that the certificate was issued to the signer by a recognized national certificate authority.
I suggest that you are a ways from coding--you need to better understand your business requirements first.
With digital signatures, protecting the security of the signers' private keys is extremely important. These days, centralized hardware-hardened appliances are often used.
Here are some APIs which make it easy to digitally sign documents and data while managing the keys via an appliance.
Disclosure: I work for CoSign.
I have three questions regarding SSL that I don't fully understand.
If I get it correctly, a server A submits a request to a certain CA. Then, it receives (after validation etc.) a digital certificate composed of a public key + identity + an encription of this information using the CA's private key.
Later on, a client B wants to open an SSL communication with A, so A sends B its digital certificate.
My question is can't B just take this certificate, thus stealing the identity A - which will allow them to authenticate as A to C, for example. I understand that C will decrypt the certificate with the CA's public key, It will then encrypt its symetric key which will only be decryptable by the real A.
However, I do not see where authentication comes to play if B can actually steal A's identity. Unless I am missing something.
Second question: Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
Thank you very much.
An SSL identity is characterized by four parts:
A private key, which is not shared with anyone.
A public key, which you can share with anyone.
The private and public key form a matched pair: anything you encrypt with one can be decrypted with the other, but you cannot decrypt something encrypted with the public key without the private key or vice versa. This is genuine mathematical magic.
Metadata attached to the public key that state who it is talking about. For a server key, this would identify the DNS name of the service that is being secured (among other things). Other data in here includes things like the intended uses (mainly used to limit the amount of damage that someone with a stolen certificate can do) and an expiry date (to limit how long a stolen certificate can be used for).
A digital signature on the combination of public key and metadata so that they can't be messed around with and so that someone else can know how much to trust the metadata. There are multiple ways to handle who does the signature:
Signing with the private key (from part 1, above); a self-signed certificate. Anyone can do this but it doesn't convey much trust (precisely because anyone can do this).
Getting a group of people who trust each other to vouch for you by signing the certificate; a web-of-trust (so called because the trust relationship is transitive and often symmetric as people sign each others certificates).
Getting a trusted third party to do the signing; a certificate authority (CA). The identity of the CA is guaranteed by another higher-level CA in a trust chain back to some root authority that “everyone” trusts (i.e., there's a list built into your SSL library, which it's possible to update at deployment time).
There's no basic technical difference between the three types of authorities above, but the nature of the trust people put in them is extremely variable. The details of why this is would require a very long answer indeed!
Items 2–4 are what comprises the digital certificate.
When the client, B, starts the SSL protocol with the server, A, the server's digital certificate is communicated to B as part of the protocol. A's private key is not sent, but because B can successfully decrypt a message sent by the other end with the public key in the digital certificate, B can know that A has the private key that matches. B can then look at the metadata in the certificate and see that the other end claims to be A, and can examine the signature to see how much to trust that assertion; if the metadata is signed by an authority that B trusts (directly or indirectly) then B can trust that the other end has A's SSL identity. If that identity is the one that they were expecting (i.e., they wanted to talk to A: in practice, this is done by comparing the DNS name in the certificate with the name that they used when looking up the server address) then they can know that they have a secured communications channel: they're good to go.
B can't impersonate A with that information though: B doesn't get A's private key and so it would all fall apart at the first stage of verification. In order for some third party to impersonate B, they need to have (at least) two of:
The private key. The owner of the identity needs to take care to stop this from happening, but it is ultimately in their hands.
A trusted authority that makes false statements. There's occasional weaknesses here — a self-signed authority is never very trustworthy, a web of trust runs into problems because trust is an awkward thing to handle transitively, and some CAs are thoroughly unscrupulous and others too inclined to not exclude the scum — but mostly this works fairly well because most parties are keen to not cause problems, often for financial reasons.
A way to poison DNS so that the target believes a different server is really the one being impersonated. Without DNSsec this is somewhat easy unfortunately, but this particular problem is being reduced.
As to your other questions…
Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?
While keys are fairly long, certificates are longer (for one thing, they include the signers public key anyway, which is typically the same length the key being signed). Hashing is part of the general algorithm for signing documents anyway because nobody wants to be restricted to signing only very short things. Given that the algorithm is required, it makes sense to use it for this purpose.
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
If you have several servers serving the same DNS name (there's many ways to do this, one of the simplest being round-robin DNS serving) you can put the same identity on each of them. This slightly reduces security, but only very slightly; it's still one service that just happens to be implemented by multiple servers. In theory you could give each one a different identity (though with the same name) but I can't think of any good reason for actually doing it; it's more likely to worry people than the alternative.
Also note that it's possible to have a certificate for more than one service name at once. There are two mechanisms for doing this (adding alternate names to the certificate or using a wildcard in the name in the certificate) but CAs tend to charge quite a lot for signing certificates with them in.
My question is can't "B" just take this certificate, thus stealing the identity of "A" - which will allow them to authenticate as "A" to "C"
There's also a private part of the certificate that does not get transmitted (the private key). Without the private key, B cannot authenticate as A. Similarly, I know your StackOverflow username, but that doens't let me log in as you.
Why use hashing on the certificate if a part of it is already encrypted by the CA?
By doing it this way, anyone can verify that it was the CA who produced the hash, and not someone else. This proves that the certificate was produced by the CA, and thus, the "validation etc." was performed.
If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.
It depends on the particular case, but you will likely have identical certificates on each.
First question: You are correct about what you get back from the CA, but you are missing part of what you need before you submit your request to the CA. You need (1) a certificate request, and (2) the corresponding private key. You do not send the private key as part of the request; you keep it secret on your server. Your signed certificate includes a copy of the corresponding public key. Before any client will believe that B "owns" the certificate, B has to prove it by using the secret key to sign a challenge sent by the client. B cannot do that without A's private key.
Second question: Typical public-key cryptography operates on fixed-size data (e.g., 2048 bits) and is somewhat computationally expensive. So in order to digitally sign an arbitrary-size document, the document is hashed down to a fixed-size block which is then encrypted with the private key.
Third question: You can use a single certificate on multiple servers; you just need the corresponding private key on all servers. (And of course the DNS name used to reach the server must match the CN in the certificate, or the client will likely balk. But having one DNS name refer to multiple servers is a common and simple means of load-balancing.)
In general, yes, if the cert file gets stolen, nothing will stop someone from installing it on their server and suddenly assuming the stolen site's identity. However, unless the thief takes over control of the original site's DNS setup, any requests for the site's URL will still go to the original server, and the thief's server will stay idle.
It's the equivalent of building an exact duplicate of the Statue of Liberty in Antarctica with the expectation of stealing away New York's tourist revenue. Unless you start hacking every single tourist guide book and history textbook to replace "New York" with Antarctica, everyone'll still go to New York to see the real statue and the thief will just have a very big, green, complete idle icicle.
However, when you get a cert from a CA, the cert is password protected and cannot simply be installed in a webserver. Some places will remove the password so the webserver can restart itself without intervention. But a secure site will keep the password in place, which means that any server restarts will kill the site until someone gets to the admin console and enters the PW to decrypt the cert.
Question N°1
can't B just take this certificate [...] which will allow them to authenticate as A to C
This part of the a larger diagram deals with that question.
Mainly : if you only have the public key then you can not establish an SSL connection with any client because you need to exchange a secret key with them and that secret key has to be encrypted using your public key, which is why the client asks for it in the first time. The client is supposed to encrypt the shared secret key with your public key and you are supposed to decrypt it using your private key. Since you don't have the private key, you can't decrypt the secret exchange key, hence you can't establish any SSL communication with any client.
Question N°2
Why use hashing on the certificate if a part of it is already
encrypted by the CA?
This is also answered in the original diagram by the question "what's a signature ?". Basically, we're hashing the whole certificate to be sure that it hasn't been tampered with (data integrity), that nobody has changed anything in it, and that what you see is really what was delivered by the CA. The diagram shows how hasing makes that possible.
Question N°3
If I am stackoverflow and I have 3 servers [...] do I have to have a
different digital certificate for each of the 3 servers.
This is not necessarily always the case. Consider the situation where all three servers are on the same domain, then you only need one certificate, if each of them is on its own subdomain you can have one single wildcard certificate installed on all of them.
On the contrary, if you have one server that hosts multiple domains you would have one single multi-domain SSL certificate.
I also have some answers.
Q1) If B steals A's certificate and try to impersonate as A to C.
C will validate the IP address of B and find out that it does not belong to C. It will then abort the SSL connection. Of course, even if C sends an encrypted message, then only the Real A will be able to decrypt it.
Q2) A certificate is usually represented in plain-text using the common format X.509. All entries are readable by anyone. The hashing process is used to digitally sign a document. Digital signing a certificate makes the end user validate that the certificate has not been altered by anyone after it was created. Hashing and encrypting the content using the issuer's private key is done to create a digital signature.
Assuming the Subject Alternative Name (SAN) property of an SSL certificate contains two DNS names
domain.example
host.domain.example
but the Common Name (CN) is set to only one of both: CN=domain.example.
Does this setup have a special meaning, or any [dis]advantages over setting both CNs?
What happens on server-side if the other one, host.domain.example, is being requested?
Specifically, how does OpenSSL 0.9.8b+ handle the given scenario?
This depends on implementation, but the general rule is that the domain is checked against all SANs and the common name. If the domain is found there, then the certificate is OK for connection.
RFC 5280, section 4.1.2.6 says "The subject name MAY be carried in the subject field and/or the subjectAltName extension". This means that the domain name must be checked against both SubjectAltName extension and Subject property (namely its common name parameter) of the certificate. These two places complement each other, not duplicate each other. And SubjectAltName is a proper place to put additional names, such as www.domain.example or www2.domain.example
Update: as per RFC 6125, published in 2011, the validator must check SAN first, and if SAN exists, then CN should not be checked. Note that RFC 6125 is relatively recent and there still exist certificates and CAs that issue certificates, which include the "main" domain name in CN and alternative domain names in SAN. In other words, by excluding CN from validation if SAN is present, you can deny some otherwise valid certificate.
To be absolutely correct you should put all the names into the SAN field.
The CN field should contain a Subject Name not a domain name, but when the Netscape found out this SSL thing, they missed to define its greatest market.
Simply there was not certificate field defined for the Server URL.
This was solved to put the domain into the CN field, and nowadays usage of the CN field is deprecated, but still widely used.
The CN can hold only one domain name.
The general rules for this:
CN - put here your main URL (for compatibility)
SAN - put all your domain here, repeat the CN because its not in right place there, but its used for that...
If you found a correct implementation, the answers for your questions will be the followings:
Has this setup a special meaning, or any [dis]advantages over setting both CNs?
You cant set both CNs, because CN can hold only one name.
You can make with 2 simple CN certificate instead one CN+SAN certificate, but you need 2 IP addresses for this.
What happens on server-side if the other one, host.domain.tld, is being requested?
It doesn't matter whats happen on server side.
In short:
When a browser client connects to this server, then the browser sends encrypted packages, which are encrypted with the public key of the server. Server decrypts the package, and if server can decrypt, then it was encrypted for the server.
The server doesn't know anything from the client before decrypt, because only the IP address is not encrypted trough the connection. This is why you need 2 IPs for 2 certificates. (Forget SNI, there is too much XP out there still now.)
On client side the browser gets the CN, then the SAN until all of the are checked.
If one of the names matches for the site, then the URL verification was done by the browser.
(im not talking on the certificate verification, of course a lot of ocsp, crl, aia request and answers travels on the net every time.)
CABForum Baseline Requirements
I see no one has mentioned the section in the Baseline Requirements yet. I feel they are important.
Q: SSL - How do Common Names (CN) and Subject Alternative Names (SAN) work together?
A: Not at all. If there are SANs, then CN can be ignored. -- At least if the software that does the checking adheres very strictly to the CABForum's Baseline Requirements.
(So this means I can't answer the "Edit" to your question. Only the original question.)
CABForum Baseline Requirements, v. 1.2.5 (as of 2 April 2015), page 9-10:
9.2.2 Subject Distinguished Name Fields
a. Subject Common Name Field
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1).
EDIT: Links from #Bruno's comment
RFC 2818: HTTP Over TLS, 2000, Section 3.1: Server Identity:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
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), 2011, Section 6.4.4: Checking of Common Names:
[...] if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID).
I've been assigned the task of buying a digital certificate for my company to sign our code. We develop applications in the Microsoft space - mostly WPF or Web Based.
I've investigated options and found Comodo to be well priced and responsive, and we're ready to go ahead and purchase a cert through them.. however in the signup form there are various private key options that I'm not too sure about, namely:
CSP
Microsoft Base Cryptographic Provider
Microsoft Base Smart Card Crypto Provider
Microsoft Enhanced Cryptographic Provider v1.0
Microsoft Software Cryptographic Provider
Key Size
1024
2048
4096
Exportable?
Yes / No
User Protected?
Yes / No
Just wondering what all of this means, and what the best options are for our requirements? Any advice/ suggestions would be appreciated
thanks heaps
Greg
For "most purposes" the following options are recommended:
Microsoft Base Cryptographic Provider
Key Size: 2048
Exportable: Yes
User Protected: Yes
To be honest, I'm not familiar with the different CSPs, but the Base does the job every time for me.
Key Size makes the keys harder to crack, but more than 2048-bits for a short to medium term key (3-5 years) is ample (IMHO).
Exportable lets you export the private key/certificate pair - essential for backing it up!
User Protected means that you must enter a password every time that you want to use the cert - highly recommended to prevent accidental or malicious signing of code with your certificate.
Historically, the "base" cryptographic provider had an artificial limitation on key lengths, and the "enhanced" provider had the limit removed. This allowed Microsoft to comply with US export laws, removing the enhanced provider in certain versions.
Apparently, with the changes to export law, Microsoft has removed the limitation from the base provider, allowing longer key lengths as well (but has kept the name for compatibility)
Regarding "Microsoft Software Cryptographic Provider" - I think that should be "strong" (not "software").
In practice where I work, base gives a 512-bit key length (which is no longer supported or working on MS servers after a recent patch - read on KB2661254). You want at least 1024, but 2048 is a better choice.
Beware: The exportable private key is desired for backing up and/or bringing to another server (and required for signing code/scripts I think), but introduces the possiblility of it falling into the wrong hands, whereupon undesirable scripts could be signed and ran on your servers once you trust that cert! Take great care in where/how you store it and use a strong passphrase!
Double-check: You most likely need the Trusted Root CA Cert (the CA that issued the code signing cert) installed as well as your cert itself in "Trusted Publishers" to get signed PowerShell scripts to run.