Skip to main content

Digital Certificates

I know this may seem out of order, since I’ve mentioned the word “certificate” multiple times already, but it’s nearly impossible to discuss PKI without mentioning certificates, and vice versa. As you can probably tell so far, a digital certificate isn’t really involved with 
encryption at all. It is, instead, a measure by which entities on a network can provide identification. A digital certificate is an electronic file that is used to verify a user’s identity, providing non-repudiation throughout the system.The certificate itself, in the PKI framework, follows a standard used worldwide. The X.509 standard, a part of a much bigger series of standards set up for directory services and such, defines what should and should not be in a digital certificate. Because of the standard, any system complying with
X.509 can exchange and use digital certificates to establish authenticity.

The contents of a digital certificate are listed-:

  • Version -This identifies the certificate format. Over time, the actual format of the certificate has changed slightly, allowing for different entries. The most common version in use is 1.
  • Serial Number- Fairly self-explanatory, the serial number is used to uniquely identify the certificate itself.
  • Subject -Whoever or whatever is being identified by the certificate.
  • Algorithm ID -(or Signature Algorithm) Shows the algorithm that was used to create the digital signature.
  •  Issuer- Shows the entity that verifies the authenticity of the certificate. The issuer is the one who creates the certificates.
  • Valid From and Valid To -These fields show the dates the certificate is good through.
  • Key Usage- Shows for what purpose the certificate was created.
  • Subject’s Public Key -A copy of the subject’s public key is included in the digital certificate, for obvious purposes.
  • Optional fields -These fields include Issuer Unique Identifier, Subject Alternative Name, and Extensions

Comments

Post a Comment

thank you for visiting :)

Popular posts from this blog

The Seven-Step Model of Migration

Irrespective of the migration approach adopted, the Seven-step Model of Cloud Migration creates a more rational point of view towards the migration process and offers the ability to imbibe several best practices throughout the journey Step 1: Assess Cloud migration assessments are conducted to understand the complexities in the migration process at the code, design and architectural levels. The investment and the recurring costs are also evaluated along with gauging the tools, test cases, functionalities and other features related to the configuration. Step 2: Isolate The applications to be migrated to the cloud from the internal data center are freed of dependencies pertaining to the environment and the existing system. This step cuts a clearer picture about the complexity of the migration process. Step 3: Map Most organisations hold a detailed mapping of their environment with all the systems and applications. This information can be used to distinguish between the ...
Post a Comment
Read more

Special Permissions in linux

The setuid permission on an executable file means that the command will run as the user owning the file, not as the user that ran the command. One example is the passwd command: [student@desktopX ~]$ ls -l /usr/bin/passwd -rw s r-xr-x. 1 root root 35504 Jul 16 2010 /usr/bin/passwd In a long listing, you can spot the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this will be replaced by an uppercase S . The special permission setgid on a directory means that files created in the directory will inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be...
Post a Comment
Read more

RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version

import tweepy /usr/lib/python2.7/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version!   RequestsDependencyWarning) Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/local/lib/python2.7/dist-packages/tweepy/__init__.py", line 14, in <module>     from tweepy.api import API   File "/usr/local/lib/python2.7/dist-packages/tweepy/api.py", line 12, in <module>     from tweepy.binder import bind_api   File "/usr/local/lib/python2.7/dist-packages/tweepy/binder.py", line 11, in <module>     import requests   File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 97, in <module>     from . import utils   File "/usr/lib/python2.7/dist-packages/requests/utils.py", line 26, in <module>     from ._internal_utils import to...
Post a Comment
Read more

tag