Entries tagged as security
Saturday, March 21. 2015
Have you ever had to fix a broken item and you didn’t have the right parts? Instead of just giving up, you looked around and found something that would work for the time being. Occasionally, you come back later and fix it “the right way,” but more often than not, that fix stays in place indefinitely. Or, perhaps you’ve found a novel new use for a device. It wasn’t built for that purpose, but you figured out that it fit the exact use you had in mind.
Those are the actions of a hacker. No, really. If you look up the definition of a hacker, you get all sort of responses. Wikipedia has three separate entries for the word hacker in relation to technology :
Google defines it as follows :
And there are more. What’s interesting here is that depending on where you look, the word hacker means different things. It has become a pretty contentious word, mostly because the media has, over time, used it to describe the actions of a particular type of person. Specifically, hacker is often used to describe the criminal actions of a person who gains unauthorized access to computer systems. But make no mistake, the media is completely wrong on this and they’re using the word improperly.
Sure, the person who broke into that computer system and stole all of that data is most likely a hacker. But, first and foremost, that person is a criminal. Being a hacker is a lifestyle and, in many cases, a career choice. Much like being a lawyer or a doctor is a career choice. Why then is hacker used as a negative term to identify criminal activity and not doctor or lawyer? There are plenty of instances where doctors, lawyers, and people from a wide variety of professions have indulged in criminal activity.
Keren Elazari spoke in 2014 at TED about hackers, and their importance in our society. During her talk she discusses the role of hackers in our society, noting that there are hackers who use their skills for criminal activity, but many more who use their skills to better the world. From hacktivist groups like Anonymous to hackers like Barnaby Jack, these people have changed the world in positive ways, helping to identify weaknesses in systems to weaknesses in governments and laws. In her own words :
It’s time to stop letting the media use this word improperly. It’s time to take back what is ours. Hacker has long been a term used to describe those we look up to, those we seek to emulate. It is a term we hold dear, a term we seek to defend. When Loyd Blankenship was arrested in 1986, he wrote what has become known as the Hacker’s Manifesto. This document, often misunderstood, describes the struggle many of us went through, and the joy of discovering something we could call our own. Yes, we’re often misunderstood. Yes, we’ve been marginalized for a long time. But times have changed since then and our culture is strong and growing.
Tuesday, March 17. 2015
I’ve recently been reading Wired for War by P.W. Singer and one of the concepts he mentions in the book is Network Enhanced Telepathy. This struck me as not only something that sounds incredibly interesting, but something that we’ll probably see hit mainstream in the next 5-10 years.
According to Wikipedia, telepathy is "the purported transmission of information from one person to another without using any of our known sensory channels or physical interaction.” In other words, you can think *at* someone and communicate. The concept that Singer talks about in the book isn’t quite as “mystical” since it uses technology to perform the heavy lifting. In this case, technology brings fantasy into reality.
Scientists have already developed methods to “read” thoughts from the human mind. These methods are by no means perfect, but they are a start. As we’ve seen with technology across the board from computers to robotics, electric cars to rockets, technological jumps may ramp up slowly, but then they rocket forward at a deafening pace. What seems like a trivial breakthrough at the moment may well lead to the next step in human evolution.
What Singer describes in the book is one step further. If we can read the human mind, and presumably write back to it, then adding a network in-between, allowing communication between minds, is obvious. Thus we have Network Enhanced Telepathy. And, of course, with that comes all of the baggage we associate with networks today. Everything from connectivity issues and lag to security problems.
The security issues associated with something like this range from inconvenient to downright horrifying. If you thought social engineering was bad, wait until we have a direct line straight into someone’s brain. Today, security issues can result in stolen data, denial of service issues, and, in some rare instances, destruction of property. These same issues may exist with this new technology as well.
Stolen data is pretty straightforward. Could an exploit allow an attacker to arbitrarily read data from someone’s mind? How would this work? Could they pinpoint the exact data they want, or would they only have access to the current “thoughts” being transmitted? While access to current thoughts might not be as bad as exact data, it’s still possible this could be used to steal important data such as passwords, secret information, etc. Pinpointing exact data could be absolutely devastating. Imagine, for a moment, what would happen if an attacker was able to pluck your innermost secrets straight out of your mind. Everyone has something to hide, whether that’s a deep dark secret, or maybe just the image of themselves in the bathroom mirror.
I’ve seen social engineering talks wherein the presenter talks about a technique to interrupt a person, mid-thought, and effectively create a buffer overflow of sorts, allowing the social engineer to insert their own directions. Taken to the next level, could an attacker perform a similar attack via a direct link to a person’s mind? If so, what access would the attacker then attain? Could we be looking at the next big thing in brainwashing? Merely insert the new programming, directly into the user.
How about Denial of Service attacks or physical destruction? Could an attacker cause physical damage in their target? Is a connection to the mind enough access to directly modify the cognitive functions of the target? Could an attacker induce something like Locked-In syndrome in a user? What about blocking specific functions, preventing the user from being able to move limbs, or speak? Since the brain performs regulatory control over the body, could an attacker modify the temperature, heart rate, or even induce sensations in their target? These are truly scary scenarios and warrant serious thought and discussion.
Technology is racing ahead at breakneck speeds and the future is an exciting one. These technologies could allow humans to take that next evolutionary step. But as with all technology, we should be looking at it with a critical eye. As technology and biology become more and more intertwined, it is essential that we tread carefully and be sure to address potential problems long before they become a reality.
Monday, October 13. 2014
In the past year we have seen several high-profile breaches of brick and mortar retailers. Estimates range in the tens of millions of credit cards stolen in each case. For the most part, these retailers have weathered the storm with virtually no ill effects. In fact, it seems the same increase in stock price that TJ Maxx saw after their breach still rings true today. A sad fact indeed.
Regardless, the recent slew of breaches has finally prompted the credit card industry to act. They have declared that 2015 will be the year that chip and pin becomes the standard for all card-present transactions. And while chip and pin isn't a silver bullet, and attackers will eventually find new and innovative ways to circumvent it, it has proven to be quite effective in Europe where it has been the standard for years.
Chip and pin changes how the credit card information is transmitted to the processor. Instead of the credit card number being read, in plain text, off of the magnetic strip, the card reader initiates an encrypted communication between the chip on the card and the card reader. The card details are encrypted and sent, along with the user's PIN, to the card processor for verification. It is this encrypted communication between the card and, ultimately, the card processor that results in increased security. In short, the attack vectors used in recent breaches is difficult, if not impossible to pull off with these new readers. Since the information is not decrypted until it hits the card processor, attackers can't simply skim the information at the card reader. There are, of course, other attacks, though these have not yet proven widespread.
At it's heart, though, chip and pin only "fixes" one type of credit card transaction, card-present transactions. That is, transactions in which the card holder physically scans their card via a card reader. The other type of transaction, card-not-present transactions, are unaffected by chip and pin. In fact, the move to chip and pin may result in putting online transactions at greater risk. With brick and mortar attacks gone, attackers will move to online retailers. Despite the standard SSL encryption used between shoppers and online retailers, there are plenty of ways to steal credit card data. In fact, one might argue that a single attack could net more card numbers in a shorter time since online retailers often store credit card data as a convenience for the user.
It seems that online fraud, though expected, is being largely ignored for the moment. After all, how are we going to protect that data without supplying card readers to every online shopper? Online solutions such as PayPal, Amazon Payments, and others mitigate this problem slightly, but we still have to rely on the security they've put in place to protect cardholder data. Other solutions such as Apple Pay and Google Wallet seemingly combine on and offline protections, but the central data warehouse remains. The problem seems to be the security of the card number itself. And losing this data can be a huge burden for many users as they have to systematically update payment information as the result of a possible breach. This can often lead to late payments, penalties, and more.
One possible alternative is to reduce the impact a single breach can cause. What if the data that retailers stored was of little or no value to an attacker while still allowing the retailer a way to simplify payments for the shopper? What if a breach at a retailer only affected that retailer and resulted in virtually no impact on the user? A solution like this may be just what we need.
Instead of providing a retailer your credit card number and CVV, the retailer is provided a simple token. That token, coupled with a private retailer-specific token should be all that is needed to verify a transaction. Tokens can and should be different for each retailer. If a retailer is compromised, new tokens can be generated, reducing the impact on the user significantly. Attackers who successfully breach a retailer can only submit transactions if they can obtain both the private retailer token as well as the user token. And if processors put simple access-control lists in place, it increases the difficulty an attacker encounters when trying to push through a fraudulent transaction.
Obtaining tokens can be handled by redirecting a user to a payment gateway for their initial transaction. The payment gateway verifies the user and their credit card data, and then passes the generated token back to the retailer. This is similar to how retailers using existing online payment processors such as Paypal and Amazon Payments already handle payments. The credit card data never passes through the retailer network. The number of locations credit card data is stored reduces significantly as well. This, in turn, means that attackers have fewer targets and while this increases the risk a payment processor network incurs, one can argue that these networks should already have significant defenses in place.
This is only one possible solution for online payments. There are many other solutions out there being presented by both security and non-security folks. But there seems to be no significant movement on an online solution. Will it take several high-profile online breaches to convince credit card companies that a solution is needed? Or will credit card companies move to protect retailers and card holders ahead of attackers redirecting their efforts? If history is any indication, get used to having your card re-issued several times a year for the foreseeable future.
Thursday, April 10. 2014
Unless you've been living under a rock the past few days, you've probably heard about the Heartbleed vulnerability in OpenSSL that was disclosed on Monday, April 7th. Systems and network administrators across the globe have spent the last few days testing for this vulnerability, patching systems, and probably rocking in the corner while crying. Yes, it's that bad. What's more, there are a number of reports that intelligence agencies may have known about this vulnerability for some time now.
The quick and dirty is that a buffer overflow bug in the code allows an attacker to remotely read memory of an affected system in 64k chunks. The only memory accessible to an attacker would be memory used by the process being connected to, but, depending on the process, there may be a LOT of useful data in there. For instance, Yahoo was leaking usernames and passwords until late Tuesday evening.
The fabulous web comic, xkcd, explains how the attack works in layman's terms. If you're interested in the real nitty gritty of this vulnerability, though, there's an excellent write-up on the IOActive Labs blog. If you're the type that likes to play, you can find proof-of-concept code here. And let's not forget about the client side, there's PoC code for that as well.
OpenSSL versions 1.0.1 through 1.0.1f as well as the 1.0.2 beta code are affected. The folks at OpenSSL released version 1.0.1g on Monday which fixed the problem. Or, at least, the current problem. There's a bit of chatter about other issues that may be lurking in the OpenSSL codebase.
Now that a few days have passed, however, what remains to be done? After all, everyone has patched their servers, right? Merely patching doesn't make the problem disappear, though. Vulnerable code is out there and mistakes can be made. For the foreseeable future, you should be regularly scanning your network for vulnerable systems with something like Nmap. The Nmap NSE for Heartbleed scanning is already available. Alternatively, you can use something like Nagios to regularly check your existing servers.
Patching immediately may not have prevented a breach, either. Since Heartbleed doesn't leave much of a trace beyond some oddities that your IDS may have seen, there's virtually no way to know if anything has been taken. The best way to deal with this is to just go ahead and assume that your private keys are compromised and start replacing them. New keys, new certs. It's painful, it's slow, but it's necessary.
For end users, the best thing you can do is change your passwords. I'm not aware of any "big" websites that have not patched by now, so changing passwords should be relatively safe. However, that said, Wired and Engadget have some of the best advice I've seen about this. In short, change your passwords today, then change them again in a few weeks. If you're really paranoid, change them a third time in about a month. By that time, any site that is going to patch will have already patched.
Unfortunately, I think the fun is just beginning. I expect we'll start seeing a number of related attacks. Phishing attacks are the most likely in the beginning. If private keys were compromised, then attackers can potentially impersonate websites, including their SSL certificates. This would likely involve a DNS poisoning attack, but could also be accomplished by compromising a user's local system and setting a hosts file entry. Certificate revocation is a potential defense against this, but since many browsers have CRL checks disabled by default, it probably won't help. Users will have to watch what they click, where they go, and what software they run. Not much different from the advice given already.
Another possible source of threats are consumer devices. As Bruce Schneier put it, "An upgrade path that involves the trash, a visit to Best Buy, and a credit card isn't going to be fun for anyone." What he's referring to are the many embedded devices we use on a daily basis that may never receive updates to protect the end user. In other words, that router you purchased from the discount store? That may be affected and unless you replace it, you'll continue to be vulnerable. Fortunately, most of these devices aren't configured, by default, to face the Internet, so there may yet be hope.
The Heartbleed vulnerability is a serious contender for the worst security vulnerability ever released. I'm not sure of another vulnerability that exposes so many systems to such a degree as this one. Network and systems administrators will be cleaning up after this one for a while.
Thursday, February 13. 2014
SSL, as I mentioned in a previous blog entry, has some issues when it comes to trust. But regardless of the problems with SSL, it is a necessary part of the security toolchain. In certain situations, however, it is possible to overcome these trust issues.
Commercial providers are not the only entities that are capable of being a Certificate Authority. In fact, anyone can become a CA and the tools to do so are available for free. Becoming your own CA is a fairly painless process, though you might want to brush up on your openSSL skills. And lest you think you can just start signing certificates and selling them to third parties, it's not quite that simple. The well-known certificate authorities have worked with browser vendors to have their root certificates added as part of the browser installation process. You'll have to convince the browser vendors that they need to add your root certificate as well. Good luck.
Having your own CA provides you the means to import your own root certificate into your browser and use it to validate certificates you use within your network. You can use these SSL certificates for more than just websites as well. LDAP, RADIUS, SMTP, and other common applications use standard SSL certificates for encrypting traffic and validating remote connections. But as mentioned above, be aware that unless a remote user has a copy of your root certificate, they will be unable to validate the authenticity of your signed certificates.
Using certificates signed by your own CA can provide you that extra trust level you may be seeking. Perhaps you configured your mail server to use your certificate for the POP and IMAP protocols. This makes it more difficult for an attacker to masquerade as either of those services without obtaining your signing certificate so they can create their own. This is especially true if you configure your mail client such that your root certificate is the only certificate that can be used for validation.
Using your own signed certificates for internal, non-public facing services provides an even better use-case. Attacks such as DNS cache poisoning make it possible for attackers to trick devices into using the wrong address for an intended destination. If these services are configured to only use your certificates and reject connection attempts from peers with invalid certificates, then attackers will only be able to impersonate the destination if they can somehow obtain a valid certificate signed by your signing certificate.
Sound good? Well, how do we go about creating our own root certificate and all the various machinery necessary to make this work? Fortunately, all of the necessary tools are open-source and part of most Linux distributions. For the purposes of this blog post, I will be explaining how this is accomplished using the CentOS 6.x Linux distribution. I will also endeavor to break down each command and explain what each parameter does. Much of this information can be found in the man pages for the various commands.
OpenSSL is installed as part of a base CentOS install. Included in the install is a directory structure in /etc/pki. All of the necessary tools and configuration files are located in this directory structure, so instead of reinventing the wheel, we'll use the existing setup.
To get started, edit the default openssl.cnf configuration file. You can find this file in /etc/pki/tls. There are a few options you want to change from their defaults. Search for the following headers and change the options listed within.
Once the openssl.cnf file is set up, the rest of the process is painless. First, switch into the correct directory.
Next, use the CA command to create a new CA.
[root@localhost misc]# ./CA -newca CA certificate filename (or enter to create) Making CA certificate ... Generating a 4096 bit RSA private key ...................................................................................................................................................................................................................................................++ .......................................................................++ writing new private key to '/etc/pki/CA/private/./cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) :MyState Locality Name (eg, city) [Default City]:MyCity Organization Name (eg, company) [Default Company Ltd]:My Company Inc. Organizational Unit Name (eg, section) : Common Name (eg, your name or your server's hostname) :cert.example.com Email Address :email@example.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password : An optional company name : Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for /etc/pki/CA/private/./cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 17886042129551798347 (0xf837fc8d719b304b) Validity Not Before: Feb 13 18:37:14 2014 GMT Not After : Feb 12 18:37:14 2017 GMT Subject: countryName = US stateOrProvinceName = MyState organizationName = My Company Inc. commonName = cert.example.com emailAddress = firstname.lastname@example.org X509v3 extensions: X509v3 Subject Key Identifier: 14:FC:14:BC:F4:A5:3E:6B:0C:58:3B:DF:3B:26:35:46:A0:BE:EC:F1 X509v3 Authority Key Identifier: keyid:14:FC:14:BC:F4:A5:3E:6B:0C:58:3B:DF:3B:26:35:46:A0:BE:EC:F1 X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Feb 12 18:37:14 2017 GMT (1095 days) Write out database with 1 new entries Data Base Updated
And that's about it. The root certificate is located in /etc/pki/CA/cacert.pem. This file can be made public without compromising the security of your system. This is the same certificate you'll want to import into your browser, email client, etc. in order to validate and certificates you may sign.
Now you can start signing certificates. First you'll need to create a CSR on the server you want to install it on. The following command creates both the private key and the CSR for you. I recommend using the server name as the name of the CSR and the key.
openssl req -newkey rsa:4096 -keyout www.example.com.key -out www.example.com.csr
[root@localhost misc]# openssl req -newkey rsa:4096 -keyout www.example.com.key -out www.example.com.csr Generating a 4096 bit RSA private key .....................................................................................................................++ ..........................................................................................................................................................................................................................................................................................................................................................................................................++ writing new private key to 'www.example.com.key' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) :MyState Locality Name (eg, city) [Default City]:MyCity Organization Name (eg, company) [Default Company Ltd]:My Company Inc. Organizational Unit Name (eg, section) : Common Name (eg, your name or your server's hostname) :www.example.com Email Address :email@example.com
Once you have the CSR, copy it over to the server you're using to sign certificates. Unfortunately, the existing tools don't make it easy to merely name the CSR you're trying to sign, so we need to create our own tool. First, create a new directory to put the CSRs in.
Next, create the sign_cert.sh script in the directory we just created. This file needs to be executable.
#!/bin/sh # Revoke last year's certificate first : # openssl ca -revoke cert.crt DOMAIN=$1 YEAR=`date +%Y` rm -f newreq.pem ln -s $DOMAIN.csr newreq.pem /etc/pki/tls/misc/CA -sign mv newcert.pem $DOMAIN.$YEAR.crt
That's all you need to start signing certificates. Place the CSR you transferred from the other server into the csr directory and use script we just created to sign it.
[root@localhost csr]# ./sign_cert.sh www.example.com Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for /etc/pki/CA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 17886042129551798348 (0xf837fc8d719b304c) Validity Not Before: Feb 13 18:48:55 2014 GMT Not After : Feb 13 18:48:55 2015 GMT Subject: countryName = US stateOrProvinceName = MyState localityName = MyCity organizationName = My Company Inc. commonName = www.example.com emailAddress = firstname.lastname@example.org X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 3A:EE:2B:3A:73:A6:C3:5C:39:90:EA:85:3F:DA:71:33:7B:91:4D:7F X509v3 Authority Key Identifier: keyid:14:FC:14:BC:F4:A5:3E:6B:0C:58:3B:DF:3B:26:35:46:A0:BE:EC:F1 Certificate is to be certified until Feb 13 18:48:55 2015 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Certificate: Data: Version: 3 (0x2) Serial Number: 17886042129551798348 (0xf837fc8d719b304c) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=MyState, O=My Company Inc., CN=cert.example.com/emailAddressemail@example.com Validity Not Before: Feb 13 18:48:55 2014 GMT Not After : Feb 13 18:48:55 2015 GMT Subject: C=US, ST=MyState, L=MyCity, O=My Company Inc., CN=www.example.com/emailAddressfirstname.lastname@example.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:d9:5a:cc:87:f0:e5:1e:6f:a0:25:cd:fe:36:64: 6c:68:ae:2f:3e:7e:93:93:a4:69:6f:f1:28:c1:c2: 4d:5f:3c:3a:61:2e:4e:f0:90:89:54:48:d6:03:83: fb:ac:1e:7c:9a:e8:be:cf:c9:8f:93:41:27:3e:1b: 66:63:db:a1:54:cb:f7:1d:0b:71:bc:5f:80:e1:30: e4:28:14:68:1c:09:ba:d0:aa:d3:e6:2b:24:cd:21: 67:99:dc:8b:7a:2c:94:d0:ed:8e:02:5f:2f:52:06: 09:0e:8a:b7:bf:64:e8:d7:bf:94:94:ad:80:34:57: 32:89:51:00:fe:fd:8c:7d:17:35:4c:c7:5f:5b:58: f4:97:9b:21:42:9e:a9:6c:86:5f:f4:35:98:a5:81: 62:9d:fa:15:07:9d:29:25:38:2b:5d:22:74:58:f8: 58:56:1c:e9:65:a3:62:b5:a7:66:17:95:12:21:ca: 82:12:90:b6:8a:8d:1f:79:e8:5c:f4:f9:6c:3a:44: f9:3a:3f:29:0d:2e:bf:51:98:9f:58:21:e5:d9:ee: 78:54:ad:5a:a2:6f:d1:85:9a:bc:b9:21:92:e8:76: 80:b8:0f:96:77:9a:99:5e:3b:06:bb:6f:da:1c:6e: f2:10:16:69:ba:2b:57:c8:1a:cc:b6:e4:0c:1d:b2: a6:b7:b9:6c:37:2e:80:13:46:a1:46:c3:ca:d6:2b: cd:f7:ba:38:98:74:15:7f:f1:67:03:8e:24:89:96: 55:31:eb:d8:44:54:a5:11:04:59:e6:73:59:42:ed: aa:a3:37:13:ab:63:ab:ef:61:65:0a:af:2f:71:91: 23:40:7d:f8:e8:a1:9d:cf:3f:e5:33:d9:5f:d2:4d: 06:d0:2c:70:59:63:06:0f:2a:59:ae:ae:12:8d:f4: 6c:fd:b2:33:76:e8:34:0f:1f:24:91:2a:a8:aa:1b: 11:8a:0b:86:f3:67:b8:be:b7:a0:06:02:4a:76:ef: dd:ed:c4:a9:03:a1:8c:b0:39:9d:35:98:7f:04:1c: 24:8a:1c:7c:6f:35:56:71:ee:b5:36:b7:3f:14:04: eb:48:a1:4f:6f:8e:43:7c:8b:36:4a:bf:ba:e9:8b: d9:38:0c:76:24:e9:a3:38:bf:4e:86:fd:31:4d:c3: 6f:16:07:09:dd:d8:6b:0b:9d:4d:97:eb:1f:92:21: b2:a5:f9:d8:55:61:85:d2:99:97:bc:27:12:be:eb: 55:86:ee:1f:f5:6f:a7:c5:64:2f:4e:c2:67:a3:52: 97:7a:d9:66:89:05:6a:59:ed:69:7b:22:10:2b:a1: 14:4e:5d:b8:f0:21:e9:11:d0:25:ae:bc:05:2b:c3: db:ad:cf Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 3A:EE:2B:3A:73:A6:C3:5C:39:90:EA:85:3F:DA:71:33:7B:91:4D:7F X509v3 Authority Key Identifier: keyid:14:FC:14:BC:F4:A5:3E:6B:0C:58:3B:DF:3B:26:35:46:A0:BE:EC:F1 Signature Algorithm: sha256WithRSAEncryption ca:66:b2:55:64:e6:40:a5:85:19:11:66:0d:63:89:fb:0d:3a: 0c:ec:fd:cb:5c:93:44:1e:3f:1b:ca:f5:3d:85:ab:0a:0b:dc: f3:18:1d:1f:ec:85:ff:f3:82:52:9e:c7:12:19:07:e9:6a:82: bd:32:f6:d1:19:b2:b7:09:1c:34:d7:89:45:7e:51:4d:42:d6: 4e:78:b6:39:b3:76:58:f8:20:57:b3:d8:7b:e0:b3:2f:ce:9f: a2:59:de:f6:31:f2:09:1c:91:3b:7f:97:61:cb:11:a4:b4:73: ab:47:64:e8:93:07:98:d5:47:75:8d:9a:8f:a3:8f:e8:f4:42: 7e:b8:1b:e8:36:72:13:93:f9:a8:cc:6d:b4:85:a7:af:94:fe: f3:6e:76:c2:4d:78:c3:c2:0b:a4:48:27:d3:eb:52:c3:46:14: c1:26:03:28:a0:53:c7:db:59:c9:95:b8:d9:f0:d9:a8:19:4a: a7:0f:81:ad:3c:e1:ec:f2:21:51:0d:bc:f9:f9:f6:b6:75:02: 9f:43:de:e6:2f:9b:77:d3:c3:72:6f:f6:18:d7:a3:43:91:d2: 04:2a:c8:bf:67:23:35:b7:41:3f:d1:63:fe:dc:53:a7:26:e9: f4:ee:3b:96:d5:2a:9c:6d:05:3d:27:6e:57:2f:c9:dc:12:06: 2c:cf:0c:1b:09:62:5c:50:82:77:6b:5c:89:32:86:6b:26:30: d2:6e:33:20:fc:a6:be:5a:f0:16:1a:9d:b7:e0:d5:d7:bb:d8: 35:57:d2:be:d5:07:98:b7:3c:18:38:f9:94:4c:26:3a:fe:f2: ad:40:e6:95:ef:4b:a9:df:b0:06:87:a2:6c:f2:6a:03:85:3b: 97:a7:ef:e6:e5:d9:c3:57:87:09:06:ae:8a:5a:63:26:b9:35: 29:a5:87:4b:7b:08:b9:63:1c:c3:65:7e:97:ae:79:79:ed:c3: a3:36:c3:87:1f:54:fe:0a:f1:1a:c1:71:3d:bc:9e:36:fc:da: 03:2b:61:b5:19:0c:d7:4d:19:37:61:45:91:4c:c9:7a:5b:00: cd:c2:2d:36:f9:1f:c2:b1:97:2b:78:86:aa:75:0f:0a:7f:04: 85:81:c5:8b:be:af:a6:a7:7a:d2:17:26:7a:86:0d:f8:fe:c0: 27:a8:66:c7:92:cd:c5:34:99:c9:8e:c1:25:f3:98:df:4e:48: 37:4a:ee:76:4a:fa:e4:66:b4:1f:cd:d8:e0:25:fd:c7:0b:b3: 12:af:bb:b7:29:98:5e:86:f2:12:8e:20:c6:a9:40:6f:39:14: 8b:71:9f:98:22:a0:5b:57:d1:f1:88:7d:86:ad:19:04:7b:7d: ee:f2:c9:87:f4:ca:06:07 -----BEGIN CERTIFICATE----- MIIGBDCCA+ygAwIBAgIJAPg3/I1xmzBMMA0GCSqGSIb3DQEBCwUAMHoxCzAJBgNV BAYTAlVTMRAwDgYDVQQIDAdNeVN0YXRlMRgwFgYDVQQKDA9NeSBDb21wYW55IElu Yy4xGTAXBgNVBAMMEGNlcnQuZXhhbXBsZS5jb20xJDAiBgkqhkiG9w0BCQEWFWNl cnRhZG1pbkBleGFtcGxlLmNvbTAeFw0xNDAyMTMxODQ4NTVaFw0xNTAyMTMxODQ4 NTVaMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHTXlTdGF0ZTEPMA0GA1UEBwwG TXlDaXR5MRgwFgYDVQQKDA9NeSBDb21wYW55IEluYy4xGDAWBgNVBAMMD3d3dy5l eGFtcGxlLmNvbTElMCMGCSqGSIb3DQEJARYWaG9zdG1hc3RlckBleGFtcGxlLmNv bTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANlazIfw5R5voCXN/jZk bGiuLz5+k5OkaW/xKMHCTV88OmEuTvCQiVRI1gOD+6wefJrovs/Jj5NBJz4bZmPb oVTL9x0LcbxfgOEw5CgUaBwJutCq0+YrJM0hZ5nci3oslNDtjgJfL1IGCQ6Kt79k 6Ne/lJStgDRXMolRAP79jH0XNUzHX1tY9JebIUKeqWyGX/Q1mKWBYp36FQedKSU4 K10idFj4WFYc6WWjYrWnZheVEiHKghKQtoqNH3noXPT5bDpE+To/KQ0uv1GYn1gh 5dnueFStWqJv0YWavLkhkuh2gLgPlneamV47Brtv2hxu8hAWaborV8gazLbkDB2y pre5bDcugBNGoUbDytYrzfe6OJh0FX/xZwOOJImWVTHr2ERUpREEWeZzWULtqqM3 E6tjq+9hZQqvL3GRI0B9+Oihnc8/5TPZX9JNBtAscFljBg8qWa6uEo30bP2yM3bo NA8fJJEqqKobEYoLhvNnuL63oAYCSnbv3e3EqQOhjLA5nTWYfwQcJIocfG81VnHu tTa3PxQE60ihT2+OQ3yLNkq/uumL2TgMdiTpozi/Tob9MU3DbxYHCd3YawudTZfr H5IhsqX52FVhhdKZl7wnEr7rVYbuH/Vvp8VkL07CZ6NSl3rZZokFalntaXsiECuh FE5duPAh6RHQJa68BSvD263PAgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4 QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBQ6 7is6c6bDXDmQ6oU/2nEze5FNfzAfBgNVHSMEGDAWgBQU/BS89KU+awxYO987JjVG oL7s8TANBgkqhkiG9w0BAQsFAAOCAgEAymayVWTmQKWFGRFmDWOJ+w06DOz9y1yT RB4/G8r1PYWrCgvc8xgdH+yF//OCUp7HEhkH6WqCvTL20RmytwkcNNeJRX5RTULW Tni2ObN2WPggV7PYe+CzL86folne9jHyCRyRO3+XYcsRpLRzq0dk6JMHmNVHdY2a j6OP6PRCfrgb6DZyE5P5qMxttIWnr5T+8252wk14w8ILpEgn0+tSw0YUwSYDKKBT x9tZyZW42fDZqBlKpw+BrTzh7PIhUQ28+fn2tnUCn0Pe5i+bd9PDcm/2GNejQ5HS BCrIv2cjNbdBP9Fj/txTpybp9O47ltUqnG0FPSduVy/J3BIGLM8MGwliXFCCd2tc iTKGayYw0m4zIPymvlrwFhqdt+DV17vYNVfSvtUHmLc8GDj5lEwmOv7yrUDmle9L qd+wBoeibPJqA4U7l6fv5uXZw1eHCQauilpjJrk1KaWHS3sIuWMcw2V+l655ee3D ozbDhx9U/grxGsFxPbyeNvzaAythtRkM100ZN2FFkUzJelsAzcItNvkfwrGXK3iG qnUPCn8EhYHFi76vpqd60hcmeoYN+P7AJ6hmx5LNxTSZyY7BJfOY305IN0rudkr6 5Ga0H83Y4CX9xwuzEq+7tymYXobyEo4gxqlAbzkUi3GfmCKgW1fR8Yh9hq0ZBHt9 7vLJh/TKBgc= -----END CERTIFICATE----- Signed certificate is in newcert.pem
The script automatically renamed the newly signed certificate. In the above example, the signed certificate is in www.example.com.2014.crt. Transfer this file back to the server it belongs on and you're all set to start using it.
That's it! You're now a certificate authority with the power to sign your own certificates. Don't let all that power go to your head!
(Page 1 of 13, totaling 63 entries) » next page
"There is no such thing as chance; and what seem to us merest accident springs from the deepest source of destiny."