Tag Info

Hot answers tagged

8

Many SMTP servers out there do support opportunistic TLS, but it's not going to really cover your needs well. It's often with self-signed certificates, you'll run into many domains you're unable to deliver mail to if you won't speak to relays without TLS, and you have no control over what a relay does with the message once you send it on its first hop - ...


8

The problem is, that the currently used infrastructure and implementation does not support intermediate certificates which are limited to only some (sub)domains. This, in effect, means that you can use any intermediate certificate to sign any certificate you want and the browsers will trust it, even if this would be certificates for domains you don't own. ...


7

No, because it would be a violation of the original certificate - browsers wuld trust your certificates and you could start issuing stuff for google.com etc. - and if you do that smart you would not be easy to get. Intermediate Certificate Authorities have a lot of power and as such no reputable certificate organization is going to give it to you.


5

This is because SANs like gateway and services are not fully qualified. In the case of services, it's actually a valid gTLD already. Others like gateway could potentially become valid at some point if ICANN decides to do so. Solution would be to fully qualify your domain names. E.g., instead of gateway, use gateway.myandy.com. Related: The tradition of ...


5

Caused by: java.net.SocketException: Permission denied You need to be root (superuser) to bind to ports under 1024. That's why 9443 works, but 443 doesn't.


4

Most likely CorpDomain.cer and CorpServices.cer are binary DER encoded CA certificate files, which you can easily convert to the base 64 PEM format with: openssl x509 -in CorpDomain.cer -inform der -outform pem -out CorpDomain.pem Afterwards you can concatenate both PEM files to form the SSLCertificateChainfile CorpChain.pem you include in the apache ...


3

I do not think that your ISP is caching anything in this regards, here are the reasons: To serve YOUR certificate with YOUR thumbprint, they need to have access to YOUR private key ISP's usually do not cache SSL traffic ISP's escpecially do not cache SSL traffic on non-standard ports So this seems to be an issue with your own server. Try rebooting it, ...


3

AH01909: sisley-mage.local.frpreprod:443:0 server certificate does NOT include an ID which matches the server name This is the problem you need to solve, the ServerName directive needs to be the same as that in the certificate openssl x509 -in server.crt -noout -subject will if you give it the correct path to your cert tell you what the CN of the ...


3

Fix your local clock. An OCSP response is valid between particular times contained within it. In general, if something comes from the future, x.509 implementations will deem it invalid (since obviously the timestamp or system time must be incorrect). However, since you're connecting via http, and not https, I don't see why you might be having trouble... ...


3

No, typically the SSL certificate is tied to the common name of a server, it's DNS name. Changing the IP-address of www.example.com does not invalidate the certificate for www.example.com. Your error message server certificate is a CA certificate suggests that you either copied the wrong certificate of misconfigured and now SSLCertificateFile points to what ...


3

Since you decided to change the port that NRPE uses for some reason (the default is 5666), you have to change the command definition for check_nrpe to match. So you'll need to add -p 15666 to the command_line, at the very least. (If you plan to run NRPE on this alternate port on every host, you can safely add the hard-coded port to the command def. But if ...


2

Yes, most modern Mail Submission/Transfer Agents (MSA, MTA) support encrypted connections via SSL/TLS and STARTTLS, including Exim, Postfix and Sendmail. Since you are concentrating on sending rather than receiving, it would be relatively easy to set up - you wouldn't have to obtain or generate a security certificate. However, there is no guarantee that the ...


2

I don't disagree with anything that's been said so far, but I thought I'd add my 2p-worth, and some data. SSL/TLS, like all security features, is designed to protect against a threat. Whether or not it's a good protection depends on the nature of the feature, and of the threat model. If your threat model includes attack by a server administrator, then no ...


2

If you want to retrieve the fingerprint of your lost public key file, you can recover it from the private key file: $ ssh-keygen -yf path/to/private_key_file > path/to/store/public_key_file Then you are able to ascertain the public fingerprint: $ ssh-keygen -lf path/to/store/public_key_file


2

First figure out if your wildcard.domain.org.key is encrypted or not. For apache to start/restart automatically it must be decrypted. You can can view it with your favorite text editor/viewer. The encrypted key would have a first like like this. -----BEGIN ENCRYPTED PRIVATE KEY----- The unencrypted key would have a first line like this. -----BEGIN RSA ...


2

If you get this issue with a Java HTTPS server running on OpenJDK, try editing /etc/java-7-openjdk/security/java.security and commenting out the line security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg as discovered by Christoph W.


2

Does it work on other browsers, for example Firefox on WinXP, IE7 on Vista/7/8, IE8+, iOS, Android? If yes, then suspecting that your cipher suite might be too restrictive/modern to allow IE7/XP. Either force your user base to upgrade their browser/OS or reconfigure your SSLCipherSuite: See ...


2

there has to be some way to prevent the server from responding to SSL requests that do not have a valid SSL associated with them Well, kinda. Since you have multiple sites running on the same IP, a user attempting an SSL connection to that IP for any of the sites will always establish its SSL connection (and potentially get a certificate error if ...


2

The JKS has certificates in DER and for Apache you want to have PEM (AKA X509) format. Sample of how to do this: $JAVA_HOME/bin/keytool --list -keystore <mykeystore> $JAVA_HOME/bin/keytool -export -rfc -alias <alias_name> -file <cert.crt> -keystore <mykeystore> So you will want to export the private key and then the certificates. ...


2

... Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs SSL needs identification of the peer, otherwise your connection might be against a man-in-the-middle which decrypts + sniffs/modifies the data and then forwards them encrypted again to the real target. Identification ...


1

The problem here is two-fold: You need to ensure that the certificate you are using can be verified from the server certificate (the one you expose) to the root CA. In Java application servers, this usually means that you use a keystore to store the private key and the matching server certificate, and a truststore to store CAs (certificate authorities). ...


1

Solved. The problem is ServerName at the head of httpd.conf. It should be removed if the main domain is defined as VirtualHost.


1

Assuming your clients always connect remotely via TLS, then yes, using basic authentication is reasonably secure. Caveat: one significant drawback of basic auth is that it requires the password be stored in cleartext (or some other easily-reversible encryption) on the server. For this reason, you may want to consider SSL client certs or at the very least ...


1

The CSR is used to generate a CRT, you need to go to godaddy and paste the CSR value from this keystore, this will generate the CRT - which you then import. At present, you are trying to add the CSR not a CRT.


1

In my server I have a empty etc/, I do not have any ssl/ subdir inside etc/ - Should I create one? I hope your /etc isn't empty, that would be bad. On EL, the normal location would be /etc/pki/tls/certs for public and /etc/pki/tls/private for private keys. Regarding the top 2 files, they re out of the question as the directories themselves don't ...


1

The errors say that Apache was looking for SSL certificate configuration for some virtual hosts, but didn't find it. You do indeed have three virtual hosts configured that are missing their SSL directives. Try adding them in.


1

you appear to be using a Debian system because it uses template files in /etc/exim4/ to generate the /var/lib/exim4/config.autogenerated file, which is what Debian's exim4 is configured to read. You can learn a lot about how Debian manages the exim installation by reading their provided file /usr/share/doc/exim4-base/README.Debian.gz. I will hereafter ...


1

I suspect that this article will help you out: Understanding SSL Support The protocol still uses TCP port 1433, by default, irrespective of SSL being used. The client can request SSL and, if the server has a certificate installed, the server and client will negotiate SSL. The server can be configured to force SSL, which will cause clients that do not ...


1

To get the HTTP requests to redirect instead of proxying, you should do two things: Move your proxying config (SSLProxyEngine through ProxyPassReverse into the SSL virtual host in /etc/httpd/conf.d/ssl.conf, so that it'll only apply there Create an HTTP virtual host which will redirect - probably in a new .conf file in /etc/httpd/conf.d: <VirtualHost ...


1

Typically you would put the SSL configuration in the frontend web server, and then simply forward without SSL to the backend server. If you have multiple backend servers, you will likely need vhosts. The nginx wiki mentions this page which even goes through a full explanation of possibly exactly what you are doing.



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