System variables. (Example : $BASH) (Conventionally in all sCAPS)
User defined variables (Conventionally in small letters)
#! /bin/bash -x
# comments example
echo "Hello Inline Comment" # This is the inline comment
# 1st System Variables #capital variables are system variables Example $BASH
# 2nd User defined Variabled # small letters
# export
echo $BASH # System Variable
echo $BASH_VERSION
echo $SHELL
echo ----------------
name=Tyson
echo The name is $name
echo Home directory is $HOME
#! /bin/bash
echo "Hello World.....Welcome to Shell Script "
File : HelloWorld.sh
The first line is the location of the bash which has to be used to execute, you can find the location of bash using command “cat /etc/shells”
#! is called shebang. It is also called sha-bang, hashbang, pound-bang, or hash-pling.
When a text file with a shebang is used as if it is an executable in a Unix-like operating system, the program loader mechanism parses the rest of the file’s initial line as an interpreter directive. The loader executes the specified interpreter program, passing to it as an argument the path that was initially used when attempting to run the script, so that the program may use the file as input data. For example, if a script is named with the path path/to/script, and it starts with the following line, #!/bin/sh, then the program loader is instructed to run the program /bin/sh, passing path/to/script as the first argument. In Linux, this behaviour is the result of both kernel and user-space code.
Some typical shebang lines:
#!/bin/sh – Execute the file using the Bourne shell, or a compatible shell, assumed to be in the /bin directory
#!/bin/bash – Execute the file using the Bash shell
#!/usr/bin/env python3 – Execute with a Python interpreter, using the program search path to find it
#!/bin/false – Do nothing, but return a non-zero exit status, indicating failure. Used to prevent stand-alone execution of a script file intended for execution in a specific context, such as by the . command from sh/bash, source from csh/tcsh, or as a .profile, .cshrc, or .login file.
Now how do you execute the file : 1. cd to the directory where the file is located 2. Then ./HelloWorld.sh 3. Now you need to give execute permission to the sh file before executing because by default linux does not give execute permission to a file. (Courtesy of umask)
In accordance to the guidelines of IT-Act and the X.509 Certificate Policy for India PKI published by Controller of Certifying Authorities, e-Mudhra issues 3 classes of Certificates, namely: Class 1, Class 2 and Class 3. Each class of digital signature certificate is associated with specific security features and corresponds to a specific level of trust.
Class 1 Certificate
Assurance Level: Class 1 certificates shall be issued for both business personnel and private individuals use. These certificates will confirm that the information in the application provided by the subscriber does not conflict with the information in well-recognized consumer databases. Applicability: This provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to be of major significance.
Class 2 Certificate
Assurance Level: These certificates will be issued for both business personnel and private individuals use. These certificates will confirm that the information in the application provided by the subscriber does not conflict with the information in well-recognized consumer databases. Applicability: This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.
Class 3 Certificate
Assurance Level: This certificate will be issued to individuals as well as organizations. As these are high assurance certificates, primarily intended for e-commerce applications, they shall be issued to individuals only on their personal (physical) appearance before the Certifying Authorities. Applicability: This level is relevant to environments where threats to data are high or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk.
The .pem file can include the server certificate, the intermediate certificate and the private key in a single file.
.crt
The server certificate
.cer
The intermediate certificate
.key
The private key can be in a .key file.
.csr (Certificate Signing request)
A CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A CSR is generally encoded using ASN.1 according to the PKCS #10 specification.
.p7b or .p7c
The PKCS#7 format is a Cryptographic Message Syntax Standard. The PKCS#7 certificate uses Base64 ASCII encoding with file extension .p7b or .p7c. Only certificates can be stored in this format, not private keys. The P7B certificates are contained between the “—–BEGIN PKCS7—–” and “—–END PKCS7—–” statements.
.der or .cer
The DER certificates are in binary form, contained in .der or .cer files. These certificates are mainly used in Java-based web servers.
.pfx or p12
The PKCS#12 certificates are in binary form, contained in .pfx or .p12 files.
The PKCS#12 can store the server certificate, the intermediate certificate and the private key in a single .pfx file with password protection. These certificates are mainly used on the Windows platform.
X.509 certificate encoding formats and extensions:
Base64 (ASCII)
PEM
.pem
.crt
.ca-bundle
PKCS#7
.p7b
.p7s
Binary
DER
.der
.cer
PKCS#12
.pfx
.p12
.csr (Certificate Signing request)
A CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A CSR is generally encoded using ASN.1 according to the PKCS #10 specification.
A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key. You need to keep your private key secret. The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.
What does a CSR look like?
Most CSRs are created in the Base-64 encoded PEM format. This format includes the “—–BEGIN CERTIFICATE REQUEST—–” and “—–END CERTIFICATE REQUEST—–” lines at the begining and end of the CSR. A PEM format CSR can be opened in a text editor and looks like the following example:
You need to generate a CSR and private key on the server that the certificate will be used on. You can find instructions in your server documentation or try the instructions from one of these certificate authorities:
Once you have your CSR generated, you can use our SSL Wizard to find the best SSL certificate that will meet your needs. If you are familiar with OpenSSL you can use the following command to generate a CSR and private key:
You can easily decode your CSR to see what is in it by using our CSR Decoder. In order to decode a CSR on your own machine using OpenSSL, use the following command:
openssl req -in server.csr -noout -text
What is a CSR/Private Key’s bit length?
The bit-length of a CSR and private key pair determine how easily the key can be cracked using brute force methods. As of 2016, a key size of less than 2048 bits is considered weak and could potentially be broken in a few months or less with enough computing power. If a private key is broken, all the connections initiated with it would be exposed to whomever had the key. The Extended Validation guidelines that SSL certificate providers are required to follow, require that all EV certificates use a 2048-bit key size to ensure their security well into the future. Because of this, most providers encourage 2048-bit keys on all certificates whether they are EV or not.
.PEM File
SSL .pem files (concatenated certificate container files), are frequently required for certificate installations when multiple certificates are being imported as one file.
This article contains multiple sets of instructions that walk through various .pem file creation scenarios.
Creating a .pem with the Entire SSL Certificate Trust Chain
Log into your DigiCert Management Console and download your Intermediate (DigiCertCA.crt), Root (TrustedRoot.crt), and Primary Certificates (your_domain_name.crt).
Open a text editor (such as wordpad) and paste the entire body of each certificate into one text file in the following order:
The Primary Certificate – your_domain_name.crt
The Intermediate Certificate – DigiCertCA.crt
The Root Certificate – TrustedRoot.crt
Make sure to include the beginning and end tags on each certificate. The result should look like this:—–BEGIN CERTIFICATE—– (Your Primary SSL certificate: your_domain_name.crt) —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– (Your Intermediate certificate: DigiCertCA.crt) —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– (Your Root certificate: TrustedRoot.crt) —–END CERTIFICATE—–Save the combined file as your_domain_name.pem. The .pem file is now ready to use.
Creating a .pem with the Server and Intermediate Certificates
Log into your DigiCert Management Console and download your Intermediate (DigiCertCA.crt) and Primary Certificates (your_domain_name.crt).
Open a text editor (such as wordpad) and paste the entire body of each certificate into one text file in the following order:
The Primary Certificate – your_domain_name.crt
The Intermediate Certificate – DigiCertCA.crt
Make sure to include the beginning and end tags on each certificate. The result should look like this:—–BEGIN CERTIFICATE—– (Your Primary SSL certificate: your_domain_name.crt) —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– (Your Intermediate certificate: DigiCertCA.crt) —–END CERTIFICATE—–Save the combined file as your_domain_name.pem. The .pem file is now ready to use.
Creating a .pem with the Private Key and Entire Trust Chain
Log into your DigiCert Management Console and download your Intermediate (DigiCertCA.crt) and Primary Certificates (your_domain_name.crt).
Open a text editor (such as wordpad) and paste the entire body of each certificate into one text file in the following order:
The Private Key – your_domain_name.key
The Primary Certificate – your_domain_name.crt
The Intermediate Certificate – DigiCertCA.crt
The Root Certificate – TrustedRoot.crt
Make sure to include the beginning and end tags on each certificate. The result should look like this:—–BEGIN RSA PRIVATE KEY—– (Your Private Key: your_domain_name.key) —–END RSA PRIVATE KEY—– —–BEGIN CERTIFICATE—– (Your Primary SSL certificate: your_domain_name.crt) —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– (Your Intermediate certificate: DigiCertCA.crt) —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– (Your Root certificate: TrustedRoot.crt) —–END CERTIFICATE—–Save the combined file as your_domain_name.pem. The .pem file is now ready to use.
Actually the question should be “why not public key encryption”
Suppose a text “abc” is encrypted with the receivers public key and during transit of this encrypted file, the file is read by a hacker. Now since the public key of the receiver is a public knowledge and hacker just have to predict the input from the sender and encrypt the predicted text with the public key of the receiver and compare. And if the text matches “vola” you have read the data sent by the sender.
Hence to avoid this type of attack PGP came into picture where the actual text sent by the sender is encrypted with a random key and the random key is encrypted by the public key of the receiver. This makes the data pretty hard to read even if it is read in transit.
You can perform PGP encryption on ubuntu using tool called Seahorse (Inbuild with ubuntu)
An SSL certificate includes the details of the party to whom the certificate has been issued. It includes the following information:
Domain Name
Certificate Validity Period
Certificate Authority (CA) Details
Public Key
Public Key Algorithm
Certificate Signature Algorithm
SSL/TLS Version
Thumbprint
Thumbprint Algorithm
The aforementioned information is included no matter which type of SSL certificate has been installed on the website. However, some additional information is also provided in the advanced level SSL certificates. For instance, organization validation (OV) and extended validation (EV) SSL certificates include details of the organization such as: