# Tag Info

10

The question's bytestring 2a 86 48 86 f7 0d 01 01 01 is the Value field of an ASN.1 BER/DER TLV with type 6, which is the Object IDentifier for an RSA key (the Type and Length just before are coded as 06 09, and won't be further discussed). In order to parse that Value bytestring, we first separate the bytes into blocks ending after each byte which ...

7

ECC is indeed used by CloudFlare's website but only for the session key agreement. The authentication is performed using an RSA 2048 bit private key. The corresponding RSA public key is in the certificate. In other words, although ECC is being used, it is not used for authentication and therefore not part of the certificate. The ciphersuite is: ...

5

There are four issues (basically all you can get at once I think) going on with your connection to this site which is why Chrome warns you. The first one is quite easy to spot: The usage of SHA-1 for the certificate signature. SHA-1 is generally considered deprecated and should not be used for scenarios where collision resistance is required, like ...

4

The short answer is that no, the length of validity would not help in a major way. First you have to consider how the attack on the collision resistance of SHA-1 applies to certificates. The idea, and how it actually worked in the case of MD5, is basically: Attacker finds a collision in the hash function that generates two certificates with the same hash. ...

4

I would think these numbers would have been put on the google search engine, and yield (probably) many hits. This assumption is wrong. Certificate serial numbers are not indexed by common search engines, nor are they typically posted to any HTML site. Frankly, I'm not sure why you would assume they'd be indexed. The Wordpress certificate is used for ...

4

Among the reason why root public keys are often expressed as a self-signed certificate are: It cryptographically protects against a deliberate alteration of an attribute of the public key (e.g. extension of validity period, or of what the key can be used for). It strongly protects against accidental alteration of the public key value. It is a reasonably ...

4

Ed25519 is well-defined and requires you to use SHA-512 as internal hash function along with the twisted Edwards version of Curve25519, hence there's no need for a KAC when it comes to questions about the parameters. As for the integrity of the public key, there's not yet a standard for Ed25519 based certificates so there would be a custom solution needed ...

3

But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ? If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can ...

3

My question is how do I authenticate my App to the CA, to prevent something else to request these Client Certificates? There is generally no way to authenticate the client code. Any secret you embed in the app could be extracted. You must assume an attacker can send requests that an authentic client would. Instead, what you can do is authenticate the ...

3

You should keep the private key as safe as possible. How safe depends on the security requirements and risk assessment. A key store, such as a PKCS#12 key store or Java key store enables you to store a key protected by - usually - a password. This is obviously more secure than storing it as plaintext at the same location. It is possible to mitigate the risk ...

3

I'm assuming you're talking about these two fields: signature signatureAlgorithm following the names defined in RFC 5280 section 4.1. And section 4.1.1.2 then goes on to state (for signatureAlgorithm): This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3). So, yes, they have to ...

3

The certificate is not encrypted. It contains signatures (basically hashes) that are encrypted with the private key. The public key can decrypt that and the hash can be verified. In SSL/TLS there is a signature that the client supplies via private key to prove they are the owner, and the CA has signed it the cert with their private key, which can be ...

2

There is no need for a trust anchor to be distributed as a certificate at all, let alone a self-signed one. The certificate path validation requirements in RFC5280 make this reasonably clear; it even says in §6.2: The path validation algorithm presented in Section 6.1 does not assume that trust anchor information is provided in self-signed certificates ...

2

Well, they say they use gpg to sign the file (yubico-utf-ca-certs.txt) and the signature is in the linked file. So gpg --verify yubico-u2f-ca-certs.txt.sig yubico-u2f-ca-certs.txt gpg: Signature made Tue Sep 2 11:18:24 2014 CEST using RSA key ID 32F8119D gpg: requesting key 32F8119D from hkp server keys.gnupg.net gpg: key 54265E8C: public key "Simon ...

2

A X.509 certificate contains the following information: The name of the subject the certificate belongs to. The public key of the subject. This public key corresponds to a private key. The subject is assumed to have exclusive access to this private key. A reference to the issuer of the certificate (e.g. VeriSign or some other certificate authority). For a ...

2

Yes, but it isn't that common and you may therefore have trouble finding implementations of it. Dave already pointed out in the other answer that you may need to use the OpenSSL API (which is a lower level crypto-API, not just SSL/TLS) rather than using the command line. Please look at the following in the X509 RFC 5280: 4.1.2.7. Subject Public Key ...

2

I'm guessing that the need for a certificate has nothing to do with authenticating the upload, but so that people's iPhones can authenticate the app at install time / runtime. [Ah, I see your edit that this is not right. I'll leave it here for posterity anyway. Are you sure you can't find documentation for this somewhere?] As a developer, you create ...

2

Signature generation and encryption are two different concepts. The fact that both can use the same one way function does not change that fact. In the case of RSA, both signature generation and encryption (as well as verification and decryption) uses modular exponentiation. These are called the RSA primitives. They have however different inputs: one uses the ...

1

You don't need to hide the certificate at all. The certificate only contains the public key and additional info of the owner (in this case the server). It shouldn't contain any private information. What you need to do is to store the certificate in such a way that you can trust the origin of the certificate. So what you need to think about is certificate ...

1

Verisign ( CA) creates a certificate after reviewing CSR, digitally signs it using it's private key and send it to organization( it signs it from it's private key for the following reasons : non-repudiation : Message integrity(using a private key as an input to the hash function) At this point organization has digital ...

1

Simply put, there are two key-pairs for DHE_RSA instead one key-pair of RSA_RSA. For example, for AES128_CBC_SHA(long name is RSA_RSA_AES128_CBC_SHA), you have one key-pair for both key-exchange and authentication. for ECDHE_RSA_AES_CBC_SHA, you have two key-pairs. The ECC key-pair is temporary for key-exchange. The RSA key-pair from cert is used for ...

1

The reason for this is because it is impossible to generate an MD5 for just any $y$, where $y$ is the output of any $x$ that isn't pre-computed. MD5 is broken but it is not completely broken. Using the common terms, MD5 is broken with regards to collision attacks, but not broken with regards to pre-image attacks. So your assumption that "Both methods ...

1

The signature value is contained in the certificate - right at the end to be precise. The signature value is not for human consumption, so it doesn't make a whole lot of sense to display it. Instead the verification result is shown. You need to parse the certificate yourself to view the signature value. For this you can use OpenSSL (openssl asn1parse) or you ...

1

Now when i am validating the certificate do i need to trace back the whole chain to validate the certificate? Not each time, no. You can do some caching, if you like (since root CAs tend to be valid for many years). But I don't think performance gains will be worth the added complexity of the caching idea. Also: if you plan to honor the expiration ...

1

Of course, since the X509 is statically signed, you have to check the signature only once.

1

You are missing the entire TLS protocol. The TLS protocol first establishes session keys. These can be randomly created at the client and send encrypted to the server. After that the session keys can be used to protect the data for confidentiality, integrity and authenticity. Encryption and authentication is performed in both directions. The TLS protocol is ...

1

You'll want to integrate something in the request that is unique for the device or the user. This can be an iOS specific identifier or a hardware specific identifier. Furthermore, what you want is to make sure that the request came from your software. You can do this by authenticating the request somehow. For this you need a secret key. I guess the most ...

1

the cert's signature algorithm and hash algorithm are sha1RSA and sha1 respectively. I was under the impression that these were obsolete and have been for quite some time? Yup, and that is indeed the problem. You're right that HMAC-SHA1 is still safe. RSA signatures, however, do not use HMAC: they just use a hash of the message to produce the ...

Only top voted, non community-wiki answers of a minimum length are eligible