Tag Info

New answers tagged

0

I ran out of space on my previous answer, but think this is valid and useful information: Revocation The next few sections discuss CRL and certificates, but before you get too far I want to draw your attention to an issue that may affect production and PKI operations: If you think your PKI will revoke twice the same certificate with Microsoft's PKI ...


0

Key distribution possible with DNSsec You can use cert pinning to distribute a key. But only if that distribution method is authenticated itself in some way. So for example, you could store the pin in DNS and secure DNS via DNSsec. Otherwise, yeah, you're back to Trust-on-first-use. And if you're not sure that your initial operating system is secure, then ...


3

You mention mobile applications. Mobile applications are typically installed from a specific vendor-controlled app store (the App Store in the case of iOS devices and the Play Store in the case of Android devices). You have to trust the store to deliver the correct binary to the device but it's still much safer than the CA system that allows any CA to sign ...


6

First of all, although you used pgp, I assume you will actually be using GnuPG. Otherwise, fetch it - it's free software. Although PGP will probably also have similar functionality. Hidden Recipients It depends. If the sender included the recipient's key fingerprints, you can retrieve them; otherwise (if encrypted using the --hidden-recipient option) ...


1

It turns out that this is pretty interesting stuff. From the Martin Kleppmann's blog "Improving the security of your SSH private key files" (Posted 2013-06-26. Archived here. HackerNews'd here): But how do you get from the passphrase to the AES encryption key? I couldn’t find it documented anywhere, so I had to dig through the OpenSSL source to find ...


1

Actually the Base CRL will have the next update time for each issuance. So the client who is verifying the CRL will first validate the signature and then the next update CRL time. In your case, if the client is using the old CRL , it will miss the new CRL entries. but for this scenario, the client needs to verify the server who issuing the base CRL regularly ...


2

Base and delta CRL are linked together through the CRL Number. The "CRL number" is a monotonically increasing integer that, roughly speaking, characterizes the age of the information contained in the CRL. From the point of view of the validator (the "client"), a delta CRL can never be used alone, but only in combination with a base CRL, subject to the ...


1

I don't think you could do this with the usual applications.. If you have your own application using the OpenSSL library you could handle this condition inside the certificate verify_callback. This callback is called on verification for each certificate in the trust chain and you can distrust the certificate by just returning 0. Note that this will cause ...


3

By trusting the Root CA you're trusting their judgement in who they sign. As long as the intermediate CA is valid, not revoked, and you're trusting the Root CA... the chain will always be verified. Other applications (such as NSS) can add additional checks and functionality to provide this, but unless the application provides it it's not really part of the ...


2

PKI-administrator is not really a well defined role, so the scope of his documentation is vague here. As a Chief Information Security Officer I would ensure that the following documents exist: System Administration doc, for a technical audience - sysadmin who need to set up servers and clients (configuration, architecture, ...). Some interesting point ...


0

If you want to use asymmetric cryptography, you cannot have multiple private key and one public key. These keys work as a pair of key. What is encrypted using the public key can only be decrypted by the private key and this key only. To solution your problem, if you have perfect control over your cluster clients, you could share the same private key among ...


0

If you want to securely send data to your recipient, you encrypt the data using the recipient's public key, not your own. Is there a specific requirement to use asymmetric keypairs? Can you use symmetric keys instead? Or you can even combine it, i.e. protect the tranport using TLS but data going through is actually encrypted using a pre-shared AES key.


3

The CSR is checked for validity. If it is valid, then the old signature is stripped out and a new certificate is built. The ingredients for the new certificate are as follows: Info from CSR (Plus some fields added/changed/removed. Whatever your CA feels is best.) Typically some basic constraints (Such as the statement: "What I'm signing here is (or is ...


1

The answer as to why you cant simply take the signed public key and use it to intercept traffic in a man-in-the-middle style attack is that you (or the attacker) wont have the corresponding private key that goes with the public key. So the browser will receive the web servers or the CAs signed public key, and will use that to encrypt its own secret to send ...


1

If you want to authenticate a client to your server, you will need a private key for each client. The usual HTTPS method (TLS) uses only one certificate to authenticate a server. The server has his public key published and signed by some authority, the client verifies the certificate and the authority signature of the certificate, then the client is sure ...


1

It's a PEM certificate that's lost its headers. OpenSSL will read it if you add back the headers. $ cat headerlesscert.txt MIICsDCCAhmgAwIBAgIJAMqzfnyqYsh+MA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV BAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBX aWRnaXRzIFB0eSBMdGQwHhcNMTQwNTEyMTMxODQ2WhcNMjQwNTA5MTMxODQ2WjBF ...


3

Key server synchronize using different protocols, forming a network of more than hundred servers all around the world involved. E-Mail Synchronization The "old" way of key server synchronization is based on the key servers sending e-mails to each other. Whenever a key server receives new information he doesn't know yet (either uploaded by a user or ...


0

The alternative to public key would be symmetric key for encryption. Usually they are combined together but if you have a trusted way of sharing the keys then you don't need PKI. However that in itself is a hard problem.


1

The identifying characteristic of PKI (public key infrastructure) is that it requires certificate authorities, which can be a problem if they abuse the trust given to them. There are some alternatives to the problem of verifying the owner of a public key without CAs, most of them are based on some sort of collective effort to establish trust, but currently ...


0

All browsers inherently trust DigiCert True enough. (and I assume it's intermediate CA?) Clients may include trusted intermediate certs, but cannot be expected to. It is your job, the server, to provide any intermediate certificates necessary to validate your certificate chain up to the root (RFC 5246 7.4.2): certificate_list This is a ...


4

You at least need : documents to describe processes involved in certificates life cycles : *request for a new certificate *certificate revocation *certificate renewal both for administrators and users (probably two different documents for each process) a general architecture document, describing CA levels and their purpose That's in my opinion ...


0

the Java keystore contains certificate information To be more precise it contains public keys or key pairs (public and private key). The keystore is protected by a password and every private key is also protected by a password. However you are able to change or remove passwords. It's up to you. A Java keystore is like a detached keystore of a web browser ...


2

If your private key ever leaked then at least the damage would be time limited. https://www.gnupg.org/gph/en/manual/c481.html


0

Since it is current, there is something else you must consider. MITM without end point control is one thing, and is pretty secure (minus certain state terrorists' weakenings), still does not account for the most effective MITM which is if they have access to your unencrypted server, game over. They can copy the private key, and perform a MAN-AT-THE-END ...


1

Set up a a ssh server to listen on port 53(DNS) somewhere, and then use winscp to connect to your server and copy things. Most sysadmins are too afraid to filter DNS ( the protocol), because of unintended consequences ( AD might not work anymore). Here's the proxy options for winscp.. http://winscp.net/eng/docs/ui_login_proxy


2

You could use any VPN software to do this, for example TunnelBlick. This works in any environment, not just locked down office environments. Indeed, it is used by people under oppressive regimes that restrict normal internet access (to Facebook, Twitter etc.). The people in China and Iran, to name a couple of examples, use this method. However, there has ...


1

I suggest to use VPN gate. Its Japanese Academic Experiment Project which is mainly used for bypass network restrictions like firewalls and proxies. link:http://www.vpngate.net


0

Yes You are right, the password is protecting the private key. First question here is that already the key got revoked , why do you want to use it the revoked one again. Is there is a intentional reason to work on it ? You can open the public part by using the keytool command.The command follows here keytool -list -keystore -storetype pkcs12 -rfc It ...


1

req -x509 (without -new) requires a CSR on input and you don't say anything about having created a CSR. -key requires a "private-key" file (which in the PKCS#1 CRT form which OpenSSL uses is really keypair) and you say you have that, although it would not normally use a .txt extension. -keyout and -nodes are useless when -key is input; they are for the case ...


2

Here's nice walkthrough of all the steps you need to do in order to generate self-signed ceritficate. http://www.akadia.com/services/ssh_test_certificate.html You are using wrong parameters. When you are generating new certificate, you've got two inputs - request and private key and one output - the signed certificate. The correct command therefore would ...


0

Yes, if it is set to be revoked the next week when a new CRL is set to be released, I would wait. Given that you said and put quotations around "probably" in reference to being valid for the remaining week, this would be a red flag to me and again, I would wait the week until next CRL. If access is not absolutely necessary and required for business ...


1

The password you are prompted for is the one used to lock the PKCS#12 file itself. PKCS#12 files are really rather generic archives, extensible in many ways, but in practice they are password-protected containers for private keys and certificates. The "password protection" really is password-based encryption: the password is turned into an encryption key ...


19

RSA is two algorithms, one for asymmetric encryption, the other one for digital signatures. They use the same kind of keys, they share the same core operation, and they are both called "RSA". Diffie-Hellman is a key exchange algorithm; you can view it as a kind of asymmetric encryption algorithm where you do not get to choose what you encrypt. This is fine ...


1

I guess from reading old white papers out there, that only the self signed root CA Certificate is not affected by the SHA-1 deprecation plan and can still use SHA-1, as clients have other means to check for integrity of root certificates. All other certs should be replaced. Here is full description: ...



Top 50 recent answers are included