Tag Info

New answers tagged

3

SSL certificates provide two things: Authentication of the organization to whom the visitor is connecting (the organization is verified to be www.foobar.com) Confidentiality of the communication (data is encrypted using the public keys in the certificate) Concerning point 2, there's no difference in using a self-signed cert, a certificate issued from a ...


-2

No, it is even less safe. If you have no knowledge of security or of certificates you should not roll your own. (luckily its not as bad as running your own CA without knowledge) CACert helps you to get the proper values in your certificates so your safe from misuse. the web of trust also means the CAcert will be on par with a face 2 face audit form a ...


2

So I decided to put my comment to "StackzOfZtuff" answer in a new post, as you can actually dissect the key exchange in more detail with this method. This answer is copied from this post over at superuser.com (so all thanks go Thomas Pornin): use openssl with its -msg option yields the information we care for openssl s_client -connect mail.example.com:143 ...


8

Do the smoke test: (stolen from OpenSSL blog. (Archived here.)) openssl s_client -connect www.example.com:443 -cipher "EDH" | grep "Server Temp Key" The key should be at least 2048 bits to offer a comfortable security margin comparable to RSA-2048. Connections with keys shorter than 1024 bits may already be in trouble today. (Note: you need OpenSSL ...


0

For some good background, please see my presentation How to Build and Operate Your Own Certificate Management Center of Mediocrity. The gist of the presentation is that the thing most required isn't a list of the commands to run, but rather a deep understanding of all the various controls that go into operating a commercial CA, how they interact together, ...


2

If you truly wish to be a CA take heed of the security implications of doing so. The private key used to generate the root CA for your intranet should literally be locked in a safe. And access to said safe should be physically monitored. Using a self signed root CA forces your users to not only trust that you are performing due diligence with the safe ...


3

Disabling RC4 completely would be great in an ideal world, but unfortunately we don't live in an ideal world. If you do disable it, certain mobile and embedded devices may not be able to communicate with you. Keep in mind that IE on Windows XP can only use RC4 because the underlying cryptographic API (CAPI) on the system doesn't have AES. As for the risk, ...


2

I think you're asking the wrong question. To me, "How much will my users be inconvenienced?", is far less important than "How sensitive is the information on this server?", or "How much would I care if it got hacked?". Hardening a system usually leads to some inconvenience. The level of inconvenience you're willing to endure (and inflict on your users) ...


0

RC4 has been proven to be broken so is probably a sensible thing to disable it from a webserver. You shouldn't bother to keep it on just to provide access to obsolete web browsers - after all, they're called obsolete for a reason, and giving the visitor incentives to upgrade his old browser is good.


11

If your infrastructure is tiny, much of the details of running a CA (e.g. CRLs and such) can probably be ignored. Instead all you really have to worry about is signing certificates. There's a multitude of tools out there that will manage this process for you. I even wrote one many years ago. But the one I recommend if you want something really simple is ...


1

Follow these instructions to configure a Windows Based CA. Since you are issuing client certificates, be aware that SHA2 hashes aren't supported on XP. The simple answer is to: Install AD Install an Enterprise CA on the Domain Controller Edit the Certificate Template to issue End User Certificates (set the permission for users to self-enroll, or go to a ...


3

There is no way to do this simply. there are some tools that can help you to easily get started. like: XCA EJBCA openssl none of them are a full PKI aside from possibly EJBCA but thats not trivial to setup. XCA is a small frontend tool to get a graphical interface to generate,sign and revoke Certificates. EJBCA or Enterprise Java Beans Certificate ...


2

Yes, they would overwrite the old SSL ceritificates. By overwriting the certificates (both key and actual certificate), you replace the certificates on your website. The visitors visiting your website will not see any error by this. Right at the moment you replace the key and certificate and restart Apache (or the webserver software you use), it will be ...


1

The public and private key have the same size (with regards to security, the file size differs of course). It's identical to the size of the modulus when it is regarded as an unsigned integer (and the key size is a full number of bytes, i.e. a multiple of 8 - otherwise it is the location of the highest bit set to one). You are however showing a full X509 ...


2

That RSA key is for authentication, not for encryption! You should not use authentication key pairs for encryption (if you literally mean extracting the ssh key to store encrypted data, rather than to share the keypair with an X509 certificate); because the public and private operations or RSA commute. For example, if you use the same key for both: ...


0

You can convert your SSH public key (id_rsa.pub) to a PEM public key file with the following Python script (cribbed from this blog post): #!/usr/bin/python # usage: sshpub2pem.py id_rsa.pub > id_rsa.pub.pem import sys, base64, struct from pyasn1.type import univ from pyasn1.codec.der import encoder as der_encoder keydata = base64.b64decode( ...


1

Note that EV certs are not structurally different -- they are just a cert issued under a different policy. So you have to check the policy. See http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification You will need to do a fairly extensive table lookup, won't be native to openssl I'm afraid. This is ...


0

Our own servers cipher suites were correct, but Embedded resources also trigger the warnings - in our case, Mixpanel (an analytics company) uses CBC on their servers: Anything other than AES-GCM or CHACHA20_POLY1305 - ie, CBC is marked as obsolete by Chrome: In order for the message to indicate “modern cryptography”, the connection should use forward ...


0

It's not up to the client no negotiate that. The server has the last word in this. Chrome can not pick anything the server is not offering. Check your server with SSL Labs (be sure to check the "Do not show the results on the boards" checkbox) https://www.ssllabs.com/ssltest/


0

Have you created a CA Singing Certificate for your CA? That is the step where you specify the details of your root CA, which will appear in all certificates that this CA creates. This answer is basically a digest of these somewhat terse instructions for setting up your CA that I found on google. So it looks like before your CA can produce any signed certs, ...


1

And that the Heartbleed bug is most vulnerable from TLS 1.1. and TLS 1.2 and NOT from TLS 1.0. It might be that your admin mixed up some facts: It is true, that Heartbleed is in a way connected to TLS 1.1 and TLS 1.2. But the connection is only, that the OpenSSL release 1.0.1 not only added support for TLS 1.1 and TLS 1.2 but also introduced support for ...


13

Your admin got it real wrong (or there was some translation mishap). TLS 1.1 and 1.2 fix some issues in TLS 1.0 (namely, predictability of IV for CBC encryption of records). It is possible to work around this issue in TLS 1.0, but it depends on how hard the implementations work at it. So, in that sense, TLS 1.1 and 1.2 are more secure than TLS 1.0, since ...


2

Whoever told you this probably doesn't quite get what Heartbleed is about: it's an implementation-specific vulnerability (in some versions of OpenSSL), it's not really related to the version of SSL/TLS. From http://heartbleed.com/: The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating ...


3

TLS 1.0 TLS 1.0 was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don't interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are: Key derivation functions are different MACs are different - SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC. The ...


0

You can use https://www.ssl2buy.com/wiki/ssl-installation-checker/ to verify SSL certificate installation.



Top 50 recent answers are included