Tag Info

New answers tagged

3

There are a few critical issues here. The errors that Apache is spitting out are telling you that the private key is failing to be parsed as valid ASN.1. This would suggest that you have extraneous data somewhere in the key such as a space. Secondly, your permissions are much too lax. The private key should be owned by root, and have the permissions similar ...


5

There are two things that may be going on here: A simple "./configure; make; make install" will by default place the shared libraries in /usr/local/lib. The system-installed libraries, however, will be in /usr/lib, which comes earlier in the library search path. Unless you remove the system-installed version of OpenSSL, the vulnerable version won't be ...


6

What server software is being used? Despite the OpenSSL binary being vulnerable, an installed web server from an OS package is likely to be using a library version that is not vulnerable. The simplest way to get a vulnerable listener running will be openssl s_server - if you need a full web server to be vulnerable, you'll likely need to compile against the ...


0

Transfer solution from question to answer section. For anyone who has this problem and can't figure it out, I found the root cause and solution. I couldn't prevent the client certificate from getting sent to Microsoft so my only option was to find out why Microsoft was rejecting the server. When creating the certificate we were using a different server ...


0

The answer (as explained in this security.SE post) is that the two GeoTrust Global CA certificate you see in the chain are in fact not the same certificate, one is derived from the other. Because of CA Cross-signing! When the GeoTrust Global CA certificate was first created and signed, no computer/browsers/applications would have had it in their trust ...


3

On a POSIX system, a disk device is a file so it can be read from by any tool which supports reading from files—be it cat, dd or even LibreOffice Writer (OK, just kidding). So basically you have two issues to sort out: How to interpret what will be read. Decide if whatever you'll observe means your test has been passed or failed. Since your disk ...


2

I think you need the seek=BLOCKS which should make dd start writing at the block next to BLOCKS of your disk address space. Supposedly you should also decrease count by that number of blocks as well.


2

No - the website can't "choose" which certificate to use. Only you can. With SNI, you can configure name-based virtual hosts to have a different certificate per host header on the same listener, which is probably what you want - configure a virtual host for the hostname listener with the hostname cert, and an IP virtual host with the IP cert (and otherwise ...


0

A way to know this is to have a look at the Ubuntu Security Notices (USN) which are released each time a vulnerability is fixed in Ubuntu. In such case, the release of the package in which it is fixed is written. For instance, for heartbleed, the USN was the USN-2165-1 (http://www.ubuntu.com/usn/usn-2165-1/) which states that it has been fixed in ...


0

verify error:num=20:unable to get local issuer certificate This error by OpenSSL means the program was unable to verify the issuer of the certificate or the topmost certificate of a provided chain. This can happen in some cases, for example: The certificate chain for the certificate wasn't provided by the other side or it doesn't have one (it is ...


2

The actual version of affected OpenSSL version in Ubuntu 12.04LTS is 1.0.1-4ubuntu5.11 and current version is 1.0.1-4ubuntu5.21 (the number at the end matters here). It's been patched a few times since and should not be affected by heartbleed bug. Here's a link from which you can see affected version numbers in different distributions: ...


1

Looking at the wget's error output and command line, the problem here is not the client-size certificate verification. It seems it's the server machine which rejects the connection. This may be due to wget not presenting a required client certificate to the server (check if your other browser have it), this particular user agent being rejected, etc. I'd ...


0

You can try to add some debugging: -S and -d for Server and client headers. tcpdump is better and will provide the full story, but next best thing is the headers w/o full packet payload. http://www.gnu.org/software/wget/manual/wget.html


2

man postconf says "You are strongly encouraged to not change this setting." Nevertheless, you can, like this: smtp_tls_security_level = encrypt smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_mandatory_ciphers=high smtpd_tls_security_level = encrypt smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_ciphers=high ...


4

From Applied Crypto Hardening by bettercrypto.org: smtpd_tls_security_level = may smtp_tls_security_level = may smtp_tls_loglevel = 1 # if you have authentication enabled, only offer it after STARTTLS smtpd_tls_auth_only = yes tls_ssl_options = NO_COMPRESSION smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_ciphers=high ...


0

It is well documented. From http://www.postfix.org/TLS_README.html#server_cipher smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5


1

The tools were not lying! The solution have to look this way: # inbound smtpd_tls_security_level = may smtpd_tls_protocols=!SSLv2,!SSLv3 smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3 # outbound smtp_tls_security_level = may smtp_tls_protocols=!SSLv2,!SSLv3 smtp_tls_mandatory_protocols=!SSLv2,!SSLv3 smtp[d]_tls_security_level == "may": ...


0

As well as Tobi's suggestion about openssl versions, you may not be installing the libraries into the correct locations. If you just run "./configure; make; make install" it will install into /usr/local/lib by default, for example. Even if you set the prefix properly, you might still be installing into /usr/lib/ rather than /usr/lib64, and ldconfig might ...


0

You've posted everything relevant except the details of the actual signed cert from your CA. I'm guessing your CA has stripped or ignored the SAN fields in your request for some reason. It should be easy enough to check with openssl. openssl x509 -in my.crt -text Assuming the SAN fields are indeed missing from the signed cert, you'll have to figure out ...


1

the 'problem' is that your ngnix is linked against a particular verion of libssl (libssl.so.10) ... your newly compiled libssl has a different version. Run ldd `which openssl` to see which version it is ... In order for ngnix to use the new version of libssl you have to recompile ngnix as well. Another option you have is to compile ...


2

One is a public cert, the other is a key. As Federico stated in comments, this question addresses it pretty well. That being said, what are you trying to do?


0

So, the question is: does crl-verify support a concatenated CRL file? No. The crl.pem is just something like this: -----BEGIN X509 CRL----- MIICAzCB7DANBgkqhkiG9w0BAQQFADCBlTELMAkGA1UEBhMCVVMxEzARBgNVBAgT CkNhbGlmb3JuaWExFTATBgNVBAcTDFJlZHdvb2QgQ2l0eTESMBAGA1UEChMJUnVu d2F5IDIwMREwDwYDVQQLEwhEZXYgVGVhbTETMBEGA1UEAxMKb3BlbnZwbi1jYTEe ...


1

According to stunnel ChangeLog, renegotiation parameter was added in stunnel version 4.54. That explains why stunnel 4.53 complains about Specified option name is not valid here The alternative solutions: Installing stunnel deb file with higher version for example stunnel for jessie (testing) or for sid (unstable) Doing self-compile stunnel


1

So I went ahead and filed a ticket with Dreamhost (Based on the analysis of @Bruno above) because I was having the same issue. It took a few weeks but they actually fixed it. Any other company they probably would have just put me in tech support hell.


1

Solved by commenting lines listen 80 default_server; listen 443 default ssl; in nginx.conf, so that they become #listen 80 default_server; #listen 443 default ssl;


0

The files server.pem and client.pem should have 3 sections in it and should look like this: -----BEGIN RSA PRIVATE KEY----- <lots of base64 encoded data> -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- <lots of base64 encoded data> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <lots of base64 encoded data> -----END ...


3

Read the VPC docs! You can configure your EC2 instance to get the same public ip address on every restart. Even if your ip address changes the CN is just the domain name. Use an A record on your DNS server to point to the public IP of the EC2 instance and the browser wont get redirected. It will resolve foo.bar.com to your EC2 instance public IP. Note ...


2

If you created the Certificate Signing Request in IIS your private key is stored there. You should be able to export the certificate as a PFX file then extract the private key using the following article. http://www.completessl.com/faq/article.php?id=027


2

Your private key lives on your server, yes. I think it lives inside the registry somewhere by default, but can easily export it using Windows' Certificate Management MMC Snapin. This process has essentially been the same since at least Windows Server 2003. Here is a walkthrough with screen shots: ...


1

In summary: I see multiple problems at the server side which might result in the problems you see. If you have access to the server try to fix them there. First it looks like the SSL stack of your target host (174.47.225.118) is kind of broken: It will do a successful handshake when SSLv23 with openssl DEFAULT cipher set is used. This will result in ...


0

Small enhancement of pQd's answer: #!/bin/bash URL=$1 RESPONSE_CODE=${2:-200} TIMEOUT=${3:-10} case $RESPONSE_CODE in 401) EXPECTED_RETURN_CODE=6 ;; 200) EXPECTED_RETURN_CODE=0 ;; *) EXPECTED_RETURN_CODE=0 ;; esac start=`date +%s` wget -t 1 --timeout ${TIMEOUT} -O /dev/null -o /dev/null -e http_proxy=PUTYOURPROXYHERE:8080 ${URL} ...



Top 50 recent answers are included