Tag Info

Hot answers tagged

25

A person with administrative (or often even physical) access to a server is going to be able to extract the private key. Whether through exporting, memory sniffing, or other such trickery. Your administrators have access to the private keys of your web servers. Accept this as fact, and work around that. If your sysadmins aren't trustworthy, then you may ...


18

RFC 2818 in "3.1. Server Identity" states that Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. So yes, it's the fact that it's two levels of subdomains that is the problem.


13

You're frequently required to provide an address (and additional verification information) for EV certs, but for "normal" certificates, you don't need to provide physical address information.


11

When you import the key, you have the option of marking it as non-exportable. This will prevent you from using IIS or the certificate MMC to export it. At least, it makes it a little harder. However, if they have an administrator account on the machine, or have physical access to it - they will still be able to get the key through other means.


5

re-use whatever cert I buy to chain trust back to Comodo for a local thatcompany.com Windows AD local root CA, which is yet to be built... ... Is there any other reason that we couldn't reuse this Comodo UC Wildcard Certificate to build a Windows local root CA? That's not possible - an end entity certificate issued to you will contain "Basic ...


5

You forgot to specify ssl_protocols and ssl_ciphers for your server named cablework.co. So the defaults - whatever they are - get used.


4

You need to have two separate bindings, one for each IP address. Each binding can have an independent certificate assigned. Two bindings can exist on a single site definition in IIS. That being said a SAN / UCC certificate will likely be the easier route to go. That will only require one IP address and binding.


4

IIS provides a certificate chain to the client using the certificates loaded in the server computer's registry. You need to obtain the missing intermediate certificate and install it onto the server so that it can provide a complete certificate chain to clients.


3

This should do it if I remember correctly. You did ask for the hash and not the modulus. echo "" | openssl s_client -connect google.com:443 | openssl x509 -noout -hash


3

... to renew my SSL certificate ... [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) [warn] RSA server certificate CommonName (CN) `proposify' does NOT match server name!? It's a wildcard certificate for *.domain.com (same as before). What am I doing wrong? Your statements do not match with the error messages. ...


3

You're probably missing the intermediate certificate. AFAIK Dovecot does not have a chain certificate option as you have in for instance Apache, you need to concatenate the intermediate certificate into a single file with your public certificate: The signed certificate for your domain Intermediate CA cert Root CA cert Get correct intermediate ...


3

Turns out this was a registry entry that was somehow removed. I can provide some details and I'm sure there will be questions but I won't be able to answer all of them without going into large detail about our environment. Regardless, here is an article detailing the fix: ...


3

The answer, based on the STARTTLS RFC for SMTP (RFC 3207) is: STARTTLS is less secure than TLS. Instead of doing the talking myself, I will allow the RFC to speak for itself, with the four relevant bits highlighted in BOLD: A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the ...


3

Another option is by a wild card cert. These typically cost more, but are much more flexible. http://en.wikipedia.org/wiki/Wildcard_certificate


3

You should use a different server block for each "type" of domain you manage, so that you don't have to use if statements to test the $host variable. # Domains to serve only via HTTPS server { server_name domaintoredirect1.tld domaintoredirect2; listen 80; return 302 https://$host$request_uri; } server { server_name domaintoredirect1.tld ...


3

It appears you're using GoDaddy to redirect https://sendsonar.com/ to the Heroku-hosted www subdomain. GoDaddy's DNS manager's redirects don't support HTTPS (as GoDaddy's redirect services servers don't have your SSL certificate installed).


2

I found a way to turn off HSTS from an answer on a Wordpress support forum of all of places: https://wordpress.org/support/topic/want-to-turn-off-http-strict-transport-security-hsts-header#post-6068192 You can send back a header that will turn off HSTS caching. Tested in Chrome with this example before_filter in a Rails 4 app: ...


2

Your server block for HTTP is missing server_name directive, and there is no server block with default_server directive specified. The default behavior of nginx is to match requests without Host: headers in that case. Your configuration should work after adding server_name directive to the HTTP server block.


2

The hostname used in the SubjectCN (optional, but common) and at least one entry in the SubjectAN (mandatory) needs to match the name by which you reference the VirtualHost (whether you gen the VirtualHost by Name (using SNI) or by IP). Additionally, you should have this hostname genned as either the main hostname or an alias in your /etc/hosts. Note, this ...


2

In your case the presence of the AJP connector in your server.xml is good indication that a webserver such as Apache with mod_ajp or mod_proxy_ajp is used as a front e.g. to off-load the serving of static content and to terminate SSL. Disabling SSLv3 then depends on the actual web server being used, in Apache some suggestions can be found on ...


2

There are two solutions to this issue: 1) You can regenerate the default self-signed certificate using OpenSSL: openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt<br/><br/> 2) You can search the Apache config files and replace the self-signed cert with the new ...


2

your ssl certificate issuer should provide you free replacement or reissue. Just go to digicert and ask them. Generate new key files from server and reissue ssl. Make sure the new ssl should be SHA2 only.


2

No, certutil doesn't have an option to add private keys. You need to use pk12util for that. If your private key is in PKCS12 format, you can add it to the key/cert database with pk12util -i keyfile.key -d/path/to/database -W password If it's in PEM format, you'll need to convert it to PKCS12 first by openssl pkcs12 -export -out server.pfx -inkey ...


2

Launch doveconf -a | grep _valid_ You have to set that variables to something like that: first_valid_uid = 26 last_valid_uid = 0 first_valid_gid = 6 last_valid_gid = 0


2

Should I install that on all of my application servers Yes. or alternatively create a new certificate and sign it with the wildcard cert That will not be possible. ... that not all of the wildcard certificates can sign others No CA will give you a certificate to sign others (at least not unless you have lots of money and a solide knowledge ...


2

You will need to forward the port(s) on your router, to the box you are hosting the site from.


2

What is you'ur threat model? What are you protecting against? What, for that matter, are you protecting? We cannot make that business decision on your behalf, nor would you want us to do so. You own the resources (transmission, processing, data, and the costs thereof), and so you must determine what risks you will accept.


2

@DanFarrell is partly correct in as much as you need the secret key to decrypt it - however if you have the secret key (ie you own the webserver thats being banned - which is implied as you say the packets are incoming) it can be decrypted - but probably not by iptables. You may be able to set up a reverse proxy (or depending on your network even offload ...


1

The EV certificate is signed with a different CA certificate than a regular certificate. Within the certificate is also an extended property that says it is an EV certificate. In practice your web browser has different collections of CA certificates as well and recognizes that the server certificate was signed by the CA certificate from the EV collection ...


1

The errors you have posted indicate that you haven't included relevant necessary SSL configuration for your domains; for any domains/subdomains you wish to be accessible via SSL, you will need to provide relevant information for the certificate, etc, in the VirtualHost configuration(s) for the domains in question, eg: <VirtualHost _default_:443> ...



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