Generating a Certificate Signing Request (CSR)
Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.
To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:
# openssl genrsa -des3 -out server.key 1024
Generating RSA private key, 1024 bit long modulus
…………………++++++
…………………++++++
Enter pass phrase for server.key:
You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive. Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.
Stealth Servers common DNS server setups
Common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary. These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference.
For example, you have 3 DNS servers; A, B and C.
A is the Primary, B and C are secondaries.
If you configure your registered domain to use A and B as your domain’s DNS servers, then C is a Stealth Secondary. It’s still a secondary, but it’s not going to be asked about the zone you are serving to the internet from A and B
If you configure your registered domain to use B and C as your domain’s DNS servers, then A is a stealth primary. Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.
Certificates
One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key. The system works by encrypting information using the public key. The information can then only be decrypted using the private key.
A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. For example, configuring Apache to provide HTTPS, the HTTP protocol over SSL.
This allows a way to encrypt traffic using a protocol that does not itself provide encryption.
A Certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certificate Authority or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.
MX recored & Time to Live (TTL)
When you add or change an MX record, the TTL setting for the previously existing MX record determines how long it takes for every DNS server to start using the new MX record.
Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like Web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimize disruptions.
When someone from another domain sends email to your domain, the domain name system (DNS) server for the sender’s domain contacts your domain’s DNS server for the prioritized list of MX records. The sender’s DNS server keeps a copy of the MX records so that it doesn’t need to contact your DNS server the next time it sends email to your domain. Each MX record includes a setting, called Time to Live (TTL), which tells the sender’s DNS server how long it can wait before contacting your domain’s DNS server to check for changes to the record.
When changing your MX records set a low TTL value so that you can quickly resolve any mistakes, or set a low TTL value for your existing records to facilitate the change.
The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.
Newer DNS methods that are part of a DR (Disaster Recovery) system may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are “per record” and setting this value on specific records is normally honored automatically by all standard DNS systems world-wide.
MX priority
The relative priority of an MX server is strong-minded by the preference number present in the DNS MX record. When a remote client does an MX lookup for the domain name, it gets a list of servers and their first choice numbers. The MX record with the smallest first choice number has the highest precedence and is the first server to be tried. The remote client will go down the list of servers until it successfully delivers the message or gets permanently rejected due to an inaccessible server or if the mail account does not exist on that server. If there is more than one entry with the same preference number, all of those must be tried before moving on to lower-priority entries.
