Self signed certificate, key of 2048 bits, CUOM 8.7

Hello:
What is the correct way to create a self signed certificate with a key of 2048 bits in Cisco Unified Operations Manager 8.7?
I edited the file
"NMSROOT\MDC\Apache\conf\ssl\openssl.conf",
changing
default_bits from 1024 to 2048 and
prompt from no to yes and then executed
"NMSROOT\MDC\Apache\gencert.bat"
and now the files
"NMSROOT\MDC\Apache\conf\ssl\server.crt" and
"NMSROOT\MDC\Apache\conf\ssl\chain.cer"
show public keys RSA of 2048 Bits.
Is this the right procedure to increase the lenght of the key?
Regards,
Marco Antonio.

Sure, the secure-server is the quickest and easiest method but you can create the new key, define the trustpoint manually and enroll the certificate that way.
Below are the commands. (You can of course call the key, trustpoint, O and CN values whatever locally significant names make sense for you.)
router(config)#crypto key generate rsa label router-rsa modulus 2048
The name for the keys will be: router-rsa
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 10 seconds)
router(config)#
router(config)#crypto pki trustpoint router-ca
router(ca-trustpoint)#enrollment selfsigned
router(ca-trustpoint)#subject-name O=Test,CN=www.router.com
router(ca-trustpoint)#rsakeypair router-rsa
router(config)#crypto pki enroll router-ca
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Generate Self Signed Router Certificate? [yes/no]: yes
Router Self Signed Certificate successfully created
router(config)#

Similar Messages

Self- Signed Certificate - Change RSA Public Key & Signature Algorithim

Hi
My 1801 router (IOS 15x) is using the original self signed certificate (1024) with an signature algorithm MD5. I would like to change the cert to a 2048 key length , with a hash of SHA1 or better but I'm unsure how to do this.
Should I just generate new keys or would I be better creating a new self-signed cert? What is the procedure & explicit commands (CLI) to do this?
Many thanks in advance.
Regards
Bob

Sure, the secure-server is the quickest and easiest method but you can create the new key, define the trustpoint manually and enroll the certificate that way.
Below are the commands. (You can of course call the key, trustpoint, O and CN values whatever locally significant names make sense for you.)
router(config)#crypto key generate rsa label router-rsa modulus 2048
The name for the keys will be: router-rsa
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 10 seconds)
router(config)#
router(config)#crypto pki trustpoint router-ca
router(ca-trustpoint)#enrollment selfsigned
router(ca-trustpoint)#subject-name O=Test,CN=www.router.com
router(ca-trustpoint)#rsakeypair router-rsa
router(config)#crypto pki enroll router-ca
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Generate Self Signed Router Certificate? [yes/no]: yes
Router Self Signed Certificate successfully created
router(config)#

Self Signed Certificates vs. GnuPG key and Web of Trust

I'm not totally sure where to ask this question, though this is the best place I can think of.
Wanting to be able to digitally sign my emails, and I can use a self signed certificate, or get one from CAcert.org (which, as far as I can tell, is also a self signature)...
Whereas with GnuPG, the keys are certified based on the web of trust.
Is there any kind of web of trust for the certificates?
Russell

Your private key is stored in the keystore (.pfx or .p12)
file that adt created for you when you created your self-sign
certificate. The file itself is protected by the password you
entered. Don't ever give this file to anyone, and under no
circumstances should you give the password to anyone.
The public key is also stored in the same file. You can
export the public key, embedded in a certificate, from the keystore
file, although you likely won't have any need to do that.
If the resulting .air file is ever modified then the
application won't install. There's no need for users to check the
hash or anything like that to validate the file; it's all done
automatically as part of the installation process.
Hope that helps,
Oliver Goldman | Adobe AIR Engineering

How to replace an expiring self-signed certificate?

Well, I've successfully (I THINK) replaced two of the three certificates that are expiring.
First off - 90% of what's in the Security manual concerning certificates is useless to this issue. I don't want to know how the watch is made - I just want to tell time! In fact there is a GLARING typo on Page 167 of the Snow Leopard Server Security Configuration Manual showing a screenshot of the Certificate Assistant in Server Admin that is just plain wrong!
It's clear there is no way to RENEW the certificate. You have to delete the old one and replace it with a new certificate.
The issue I have is that with all the services using the certificate, I don't know what the impact to the end-users is going to be when I delete that expiring certificate.
It appears that a certificate is created automatically when the OS is installed, although I installed the OS Server on a virtual machine and I didn't see where it got created, nor was I given any input during the creation (like extending the expiration date).
I don't know whether those certificates are critical to the running of the OS or not, but I went through the process of creating a new certificate in Server Admin. I deleted the expiring certificate. Because the two servers on which the expiring certificate was deleted does not have any services running that require a certificate (such as SSL on my mail server), nothing bad seems to have happened or been impacted negatively.
I did, however, name the new certificate the exact same thing as the old certificate and tried to make sure that the parameters of the new certificate were at least as extensive as the old certificate. You can look at the details of the old certficate to see what they were.
Here's the "critical" area of the certificate that was "auto-created" on my virtual server. (It's the same as the one on my "real" server.
http://screencast.com/t/zlVyR2Hsc
Note the "Public Key Info" for "Key Usage": Encrypt, Verify, Derive. Note the "Key Usage" Extension is marked CRITICAL and it's usage is "Digital Signature, Data Encipherment, Key Cert Sign". Extended Key Usage is also critical and it's purpose is Server Authentication.
Here's a screenshot of the default certificate that's created if you create a new self-signed certificate in Server Admin:
http://screencast.com/t/54c2BUJuXO2
Note the differences between the two certificates. It LOOKS to me like the second certificate would be more expansive than the default issued at OS Install? Although I don't really care about Apple iChat Encryption.
Be aware that creating certificates starts to populate your server Keychain.
http://screencast.com/t/JjLb4YkAM
It appears that when you start to delete certificates, it leaves behind private keys.
http://screencast.com/t/XD9zO3n16z
If you delete these keys you get a message warning you about the end of the world if you delete private keys. I'm sorry if your world melts around you, but I'm going to delete them from my Keychain.
OK, now I'm going to try to create a certificate that is similar to the one that is created at start-up.
In Server Admin, highlight your server on the sidebar and click the "Certificates" tab in the icon bar.
Click the "+" button under your existing certificate and select "Create a Certificate Identity". (This is how I created the default certificate we just got through looking at except I clicked through all the defaults.)
Bypass "Introduction".
In the "Create Your Certificate" window I set the "Name" as exactly the same as the name of the expiring certificate. I'm HOPING when I do this for my email server, I won't have to go into the services using the certificate and select the new one. On the other hand, naming it the same as the old one could screw things up - I guess I'll know when I do it later this week.
The "Certificate Type" defaults to "SSL Server" and I think this is OK since that's what I'll be using this certificate for.
You HAVE to check the "Let me override defaults" if you want to, for example, extend the expiry period. So that's what I want to do, so I checked it.
In the next window you set the Serial Number and Validity Period. Don't try typing "9999" (for an infinite certificate) in the "Validity Period" field. Won't work - but you CAN type in 1826 (5 years) - that works - Go Figure!??? You can type in a bigger number than that but I thought 5 years was good for me.
The next part (Key Usage Extension) is where it gets sticky. OF COURSE there is NO DOCUMENTATION on what these parameters mean of how to select what to choose.
(OK here's what one of the "explanations" says: "Select this when the certificate's public key is used for encrypting a key for any purpose. Key encipherment is used for key transport and key wrapping (or key management), blah, blah, blah, blah, blah blah!") I'm sure that's a clear as day to you rocket scientists out there, but for idiot teachers like me - it's meaningless.
Pant, pant...
The next window asks for an email address and location information - this appears to be optional.
Key Pair Information window is OK w/ 2048 bits and RSA Algorithm - that appears to be the same as the original certificate.
Key Usage Extension window
Here's where it gets interesting...
I brought up the screenshot of the OS Install created certificate to guide me through these next couple of windows.
Since the expiring cert had "Digital Signature, Data Encipherment, Key Cert Sign" I selected "Signature, Data Encipherment and Certificate Signing".
Extended Key Usage Extension...
Hoo Boy...Well, this is critical. But under "Capabilities" it lists ANY then more stuff. Wouldn't you THINK that "ANY" would include the other stuff? Apparently not..."Learn More"?
Sorry, folks, I just HAVE to show you the help for this window...
+*The Extended Key Usage Extension (EKU) is much like the Key Usage Extension (KUE), except that EKU values are defined in terms of "purpose" (for example, signing OCSP responses, identifying an SSL client, and so on.), and are easily extensible. EKU is defined with object identifiers called OIDs. If the EKU extension is omitted, all operations are potentially valid.*+
KILL ME NOW!!!
OK (holding my nose) here I go...Well, I need SSL Server Authentication (I THINK), I guess the other stuff that's checked is OK. So...click "Continue".
Basic Constraints Extension...
Well, there is no mention of that on the original certificate, so leave it unchecked.
Subject Alternate Name Extension...
Nothing about that in the original certificate, so I'm going to UNCHECK that box (is your world melting yet?)
DONE!!!! Let's see what the heck we got!
http://screencast.com/t/QgU86suCiQH
Well, I don't know about you but that looks pretty close for Jazz?
I got some extra crap in there but the stuff from the original cert is all there.
Think we're OK??
Out with the old certificate (delete).
Oh oh - extra private key - but which is the extra one? Well, I guess I'll just keep it.
http://screencast.com/t/bydMfhXcBFDH
Oh yeah...one more thing in KeyChain Access...
See the red "X" on the certificate? You can get rid of that by double clicking on the certificate and expanding the "Trust" link.
http://screencast.com/t/GdZfxBkHrea
Select "Always Trust".
I don't know if that does anything other than get rid of the Red "X", but it looks nice. There seem to be plenty of certificates in the Keychain which aren't trusted so maybe it's unnecessary.
I've done this on both my file server and my "test" server. So far...no problems. Thursday I'll go through this for my Mail server which uses SSL. I'm thinking I should keep the name the same and not replace the certificates in the iCal and Mail service which use it and see what happens. If worse comes to worse, I may need to recreate the certificate with a different name and select the new certificate in the two services that use it.
Look...I don't know if this helps anyone, but at least I'm trying to figure this idiocy out. At least if I screw up you can see where it was and, hopefully, avoid it yourself.
If you want to see my rant on Apple's worthless documentation, it's here.
http://discussions.apple.com/thread.jspa?threadID=2613095&tstart=0

to add to countryschool and john orban's experiences:
using the + Create a Certificate Identity button in Server Admin is the same thing as running KeyChain Access and selecting Certificate Assistant from the app menu, and choosing Create a Certificate. Note that you don't need to create a Certificate Authority first.
in the second "extended key usage extension" dialog box, i UN-checked Any, PKINIT Server Authentication, and iChat Encryption. this produced the closest match to the server's default self-installed certificate.
when updating trust settings in Keychain Access, the best match to the original cert are custom settings - set Always Trust for only SSL and X.509 Basic Policy.
supposedly you can use Replace With Signed or Renewed certificate button from Server Admin and avoid needing to re-assign to services. however i was unable to get this to work because my new cert didn't match the private key of the old. for those interested in going further, i did figure out the following which might be helpful:
you can't drag and drop a cert from Keychain Access or Cert Manager. you need the actual PEM file. supposedly you can hold down the option button while dragging, but this didn't work for me. however you can view the certificates directly in etc/certificates. but that folder is hidden by default. a useful shortcut is to use Finder / Go To Folder, and type in "/private/etc/certificates"
now, on my system the modification date was the same for old and new certificates. why? because it seems to be set by when you last viewed them. so how do you know which is which? answer: compare file name to SHA1 Fingerprint at bottom of certificate details.
after you delete the old certificate, it will disappear in Keychain Access from "System" keychains. however in "login" keychains the old one will still be there but the new one won't. it seems to make sense to delete the old one from here and add the new one. somebody tell me if this is a bad idea. the + button does not work easily for this, you need to drag and drop from the etc/certificates folder.
lastly, the "common name" field is the server/host name the client will try to match to. you can use wildcard for this, e.g. *.example.com. if you need to, you can use the Subject Alternate Name to provide an alternative name to match to, in which case the common name field will be ignored, which is why by default the dNSName alternate field defaults to the common name. more info here: http://www.digicert.com/subject-alternative-name-compatibility.htm.
maybe that's hopeful to somebody. but i stopped there since things seem to be working.
last note, which you probably know already - if you don't want to bother installing the certificate in your client computers and phones, you can select Details when the first trust warning pops up and select Always Trust.
now, we'll see how everything works once people start really using it...

Lion server erased self signed certificate

Help!!! I accidentally deleted the self signed certificate that had the right keys for my third party SSL. Now I cannot replace the self signed certificate with the new SSL. Now what????

I will begin my answer by making an emphasis that the best way to protect your data in-transit is using a 2048 bit certificate signed by a trusted certificate authority (CA) instead of relying on the self-signed certificate created by SQL Server.
Please remember that the self-signed certificate created by SQL Server usage for data in-transit protection was designed as a mitigation against passive traffic sniffers that could potentially obtain SQL Server credentials being transmitted
in cleartext, but nothing more. Think of it as a mitigation against a casual adversary.
The self-signed certificate usage was not intended to replace real data in-transit protection using a certificate signed by a trusted CA and encrypting the whole communication channel. Remember, if it is self-signed, it is trivial to spoof.
After making this clarification, the self-signed certificate generated by SQL Server uses a 1024 bit key, but that size may be subject to change in future versions of the product. Once again, I would like to strongly discourage relying on the self-signed
certificate created by SQL Server for data in transit transmission.
BTW. Azure SQL Database uses a 2048 certificate issued by a valid certificate authority.
I hope this information helps,
-Raul Garcia
SQL Server Security
This posting is provided "AS IS" with no warranties, and confers no rights.

SQL Server 2008 self-signed certificate is 1024bit or 2048bit?

When there is no user defined certificate available, SQL Server will generate a self-signed certificate when service starts, We have a tool scans and finds that in SQL 2005 the self-signed certificate is 1024bit, does someone know the default self-signed
certificate is still 1024bit or is it 2048bit in SQL 2008? Thanks a lot!!!

I will begin my answer by making an emphasis that the best way to protect your data in-transit is using a 2048 bit certificate signed by a trusted certificate authority (CA) instead of relying on the self-signed certificate created by SQL Server.
Please remember that the self-signed certificate created by SQL Server usage for data in-transit protection was designed as a mitigation against passive traffic sniffers that could potentially obtain SQL Server credentials being transmitted
in cleartext, but nothing more. Think of it as a mitigation against a casual adversary.
The self-signed certificate usage was not intended to replace real data in-transit protection using a certificate signed by a trusted CA and encrypting the whole communication channel. Remember, if it is self-signed, it is trivial to spoof.
After making this clarification, the self-signed certificate generated by SQL Server uses a 1024 bit key, but that size may be subject to change in future versions of the product. Once again, I would like to strongly discourage relying on the self-signed
certificate created by SQL Server for data in transit transmission.
BTW. Azure SQL Database uses a 2048 certificate issued by a valid certificate authority.
I hope this information helps,
-Raul Garcia
SQL Server Security
This posting is provided "AS IS" with no warranties, and confers no rights.

Can you use a self signed certificate on an external Edge Server interface?

Hi,
I have a small lab deployment for evaluation purposes. The Lync FE server works great for internal users. I have now added an Edge server. For the internal interface, I have a self signed certificate from our internal CA. (no problem there) For the external
interface, I have a self signed certificate from our own external CA. I have installed the cert on the client machine of the external user and installed it for trusted operation. I have used the RUCT and digicert tools to prove that the external self signed
cert is valid (root and intermediate have been checked for validity).
At first, when logging in from the Lync 2013 client on the external users machine, I would get an error from Lync about the cert being untrusted. I have now fixed that error by adding it as trusted. At this point, there are no errors or warnings in the Event
Viewer (in the application or system logs) However, I receive the following error from the Lync client, "Were having trouble connecting to the server... blah, blah".
Here is my question. Does the Microsoft Lync 2013 client and/or the "testconnectivity.microsoft.com" tool specifically prevent or forbid the use of self signed certificates on the external interface of an Edge server? They seem too.
I can tell if the certificate is my problem or something else. Any ideas on how to trouble shoot this?
Thx

Drago,
Thanks for all your help. I got it working.
My problem with the Lync client error, "Were having trouble connecting to the server... blah, blah", was NOT a certificate error. It was a problem with my Lync Server Topology. (My sip default domain needed to match my user login domain.)
Let me update everyone about self-signed certificates:
YES, you can self-sign a certificate on your external edge server. It is a pain, but possible.
I have a self signed certificate from our own external CA. I have installed the cert on the client machine of the external user for trusted operation. I have used the RUCT and digicert tools to prove that the external self signed cert is valid (root and
intermediate have been checked for validity).
Here are my notes:
Create/enable your own external Certificate Authority (CA) running on a server with internet access.
On the Lync Edge Server, run the "Lync Server 2013 - Development Wizard".
Click "Install or Update Lync Server System". (Lync will automatically determine its deployment state)
You should have already completed: Step1 and Step 2.
Run or Run Again "Step 3: Request, Install or Assign Certificates".
Install the "Edge internal" certificate.
Click "Request" button to run the "Certificate Request" wizard.
You use can "Send the request immediately to an online certificate authority" option to connect to your internal CA, and create the certificate.
Once the certificate has been created, use "Import Certificate" to import it.
Once imported, on the Edge Server, go to: (Control Panel -> Administrative Tools -> Internet Information Services (ISS) Manager -> Server Certificates -> Complete Certificate Request...
In the Lync deployment wizard - Certificate Wizard, "Assign the newly imported "edge internal" certificate.
Install the "Edge External" certificate (public Internet).
Click the "Request" button to run the "Certificate Request" wizard.
Press "next"
Select "Prepare the request now, but send it later (offline certificate request).
Supply the "Certificate Request File" name and location. (You will need the file later. It should have the file extension ".req").
Click next on the "Specify Alternate Certificate Template". (which means you are using the default options)
Give it a Friendly Name. Bit Length = 2048. I selected "Mark the certificate's private key as exportable" option.
Fill in the organization info.
Fill in the Geographical Information.
The wizard should automatically fill-in the "Subject name:" and "subject alternative name:' fields.
Select your "Configured SIP domains"
"Configure Additional Subject Alternative Names" if you want. Otherwise, next.
Verify the "certificate Request Summary". Click next.
Run the wizard script to "Complete". The wizard will create a file containing the certificate request with the file extension ".req". (Let's assume the file name is "myCert.req")
Move your myCert.req file to your external CA. Have your CA issue the cert (based on myCert.req) and export the new cert to a file. I save it as a P7B certificate. (Let's call it "ExternalCert.p7b")
In the Lync Deployment wizard - Certificate Wizard, click on "Import Certificate" for ExternalCert.p7b.
Once imported, on the Edge Server, go to: (Control Panel -> Administrative Tools -> Internet Information Services (ISS) Manager -> Server Certificates -> Complete Certificate Request... (assign it a friendly name. Let's say "EXTERNAL-EDGE")
For the "External Edge certificate (public Internet), click "Assign".
The "Certificate Assignment" wizard will run.
Click next.
From the list, select your cert "EXTERNAL-EDGE".
Finish the wizard to "complete".
You are finished on the server.
Move the "ExternalCert.p7b" file to the machine running the lync client. Install the cert via the "Certificate Import Wizard".
When installing it to a particular Certificate Store, select the "Place all certificates in the following store" option.
Browse
Select "Trusted Root Certification Authorities"
Finish the wizard.

Renewing Self Signed Certificate on IPN Nodes 1.2

Dear Team
I have just upgraded the ISE infrastructure to 1.2, IPN nodes have also been upgraded, a default self signed certificate is generated, which is for a validity of 90 days.
on my ISE main units, i have self signed certificates with 2048 Modulas and SHA1-256 hash, validity = 12 years.
1: I want to generate self signed certificate on IPN with the same specifications.
how it can be achieved, is it through "pep certificate server add" ?
IPN2/admin# pep certificate server add
Server Certificate change will result in application restart. Proceed? (y/n): y
Bind the certificate to private key made by last certificate signing request? (y/n):
but as such i am not generating any CSR, because we do not have any CA in our deployment.
Thanks
Ahad Samir

Above requirement is necessary because we don't have an Enterprise CA in our Deployment. We have to rely on self Signed certificates.
Further Self Signed certificates should be valid for a long period so that no communication issue happens,

Ssl_error_internal_error_alert error in firefox when connecting to an internal website with self signed certificate.

Firefox 26.0 . The website is running on tomcat 7 server . Using java key store .java version "1.6.0_29"
Can test the site with openssl s_client and response seem ok.
SSL handshake has read 2335 bytes and written 303 bytes
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
SSL-Session:
Protocol : TLSv1
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: 52B896D8E3B7D0B1A03C5D2E5FF8B594D6AA74E94CB193E24685A041C5BEBF3A
Session-ID-ctx:
Master-Key: 1063AB71B3389D139FD7DD490FE3DF2188FA24B5E090390D2A899B32E2895B1D7A093590BE8D6FCDEFD22ACF10D94544
Key-Arg : None
Start Time: 1387828953
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
closed

Hello,
Can you please confirm what the issue is? Are you not able to setup a SSL connection to the internal website running on Tomcat. If so, have you tried installing the root CA certificate into Firefox? You can do that by going to Firefox -> Preferences -> Advanced -> View Certificates -> Certificate Authorities and then importing the root CA certificate.
Please check this and let us know if this helps in resolving the connectivity issue. Though, I am a bit surprised that the connection is not getting established. Typically, Firefox would warn you if you would like to continue with the connection. Are you not seeing this warning?
Thank you

Help w/ self-signed certificate in SunOne 5.2 P4

I'm running SunOne 5.2 P4 and I'm very new to the whole SSL thing and want to enable SSL in SunOne for some testing.
However, all attempts at generating and importing a certificate of varying lengths (512, 1024, 2048, 4096 bits) results in the following error in the Certificate Install Wizard of the Console:
"Either this certificate is for another server, or this certificate was not requested using this server."
Could someone point me to some instructions or walk me through the steps for generating self-signed certificates so they will import correctly? All the instructions I have seen so far say to send the "Certificate Request" to a CA for signing. I don't want to do that. I just need it for testing and would like to know how to do it locally. I assume this means self-signing it.
Thanks!!

It's not necessarily the server-certificate itself that is self-signed. My guess is that the CA that signed this certificate uses a self-signed certificate for itself.
Your certificate chain might look like this:
Your certificate <<signed by>> Your CA <<signed by>> Your CA
Your CA isn't a trusted issuer by default, therefore you need to import the CA's certificate into the truststore.

How to successfully import ASA self-signed certificate?

On ASA 9.1 i am trying to export an Identity certificate, self-signed certificate into p12 file so i can import it into laptop and used it for secure connection to ASA over ASDM. I can add certificate OK using ASDM, certificate show up OK in Certificate management/dentity certificate. Exported certificate into .p12 file with passphrase OK.
In Win XP and Windows 7 every time i try to import certificate i got message that password is incorrect. Yes, i did type correct password.
Even thru cli i got the same error when trying to import the file.
ASA(config)# crypto ca export ASDM_TRUSTPOINT pkcs12 password
Exported pkcs12 follows:
-----BEGIN PKCS12-----
MIIHPwIBAzCCBvkGCSqGSIb3DQEHAaCCBuoEggbmMIIG4jCCBt4GCSqGSIb3DQEH
BqCCBs8wggbLAgEAMIIGxAYJKoZIhvcNAQcBMBsGCiqGSIb3DQEMAQMwDQQItd0L
7e5QezkgxXzmCJKpv3GqQV5/tfk66ySnBMCGrMzsQKBa32wzHYcSerSEePNXzudJ
Frdyc3ETMXECvO83gujQZLyJ9DfPaDy4gZHwEs9fwGqpJel/NTwUo16dtzO2Vbko
1kc8kd
-----END PKCS12-----
Any tips or tricks how to get this simple task completted? Is maybe file format not right?

Hi
Please show the error ASA is reporting during import.
It's working correctly with 9.1(0)2, example:
ASA9(config)# crypto ca trustpoint TP
ASA9(config-ca-trustpoint)# enrollment self
ASA9(config)# crypto ca enroll TP
WARNING: Trustpoint TP has already enrolled and has
a device cert issued to it.
If you successfully re-enroll this trustpoint,
the existing certificate will be replaced.
Do you want to continue with re-enrollment? [yes/no]: yes
% The fully-qualified domain name in the certificate will be: ASA9
% Include the device serial number in the subject name? [yes/no]: yes
Generate Self-Signed Certificate? [yes/no]: yes
ASA9(config)#
ASA9(config)# crypto ca export TP pkcs12 123456
Exported pkcs12 follows:
-----BEGIN PKCS12-----
MIIGHwIBAzCCBdkGCSqGSIb3DQEHAaCCBcoEggXGMIIFwjCCBb4GCSqGSIb3DQEH
BqCCBa8wggWrAgEAMIIFpAYJKoZIhvcNAQcBMBsGCiqGSIb3DQEMAQMwDQQIp8j1
+5Rh9TQCAQGAggV4DUlYOI+VlGxuCXiGnDTYx+cR5XjPca7KW7L50D5lLQQHLr+U
fV+QVEaELnQ1MKsMm87zl9AuycuI9EeOJnPTF9Ddxy32ODzaZ4/3BaXnHl2ETyzM
IohydDJCfscT0r2TPNlE8XSknDfftK+3g3Aa0Gi+Nsq1+NXxTdYcfdXpZHvD9tk0
QZInQy1UG+NhCERyOe6SIbynuCBfksk9g+rRjeNW4bTNRDpCJ1DnrtpN6BCq8VGN
QMQagUZ1ONNLaFtQegd17RxWzXUZiWQgqf0jUZnr/BJQI9bPrISkA+JnysNU3MvS
WVKKfyGQcsYD4ExH+wi6xkohKi7hj80s9cFOyq+xpXjikZw9gKMcpoY2lLs4ivIl
4x9bB3EQ3xYW5nxbORwDx5xEyYLMUNkVRvC14ts+RB2QcEAXwq2JaaNuO6aBvjhj
8mpHjXR+wkxV8Mm+UYEed2f1SuzjtZ966OPYW0YkmXGTH+wt/rxbCROAqnmh6HGz
pU4H5/yhHgBIJOd6vZaKf5XlnX17wSniM+JRw4FsArVpuNOZFeCkDsHHFP6TPYII
h2aS2jBEH2KW0KuzEP0rHOJ8WVjZgVucSu0pb+vVGw3MzsBl14CnL5kZcPe+81wJ
XnFibhkucyo9arO/kcc7OtMcAuoktGfBVb1jrX6Se/SY8GFrzYbikNuT4DI4/dw+
OinRXOX7S/Bhaefx4JSFYoL/7agD7f+kwzv7qAEyIQtjxoGgYuqY2lZVsbZL05dJ
0D3xDkSDOc9H/5M5nZqP/xwnqVMoREPvt/a+ZdGezfzApUYUH/VAU4NzST44QcvM
mdeeizpj0VwA7WdZOrMaJll927NGb1RikmtE+6ITgdiksuJVOeNWcXuq00sDAxvZ
fv7tOQxgWX0+LNKaFd1Ef7PF9KqsJLQnbC28GC9GBNExcc9Pm+Kqfq6qj7HEosHt
kPSfLFs0kkQQzq+G4xH6pzKQkG7Yt3xjLblI9IdWsCvuHLl8fgN0LHpVXPi9iftW
PqGG8f9dCymAqHKFEnZzOiCcNlKKG+ddAN7Qb4mGVBYsaeROvVWBL2aAzIDpL7Uv
8rFHsJVKk/yCruuNSDjmbbaTlYxb2iglo2MkgGsCO5X7fOPTCO3C+UikFyOi6/7c
fSyn+LE6Za76kdRn4V2FHGG767nBxFBR/bB+uzngR+w/GzIgHQahpJ2xJlKumS2M
yiy3kGYDhIN+WV6Lz91YwZpSobk1qrcn/7fzl2FFaY6+3+AgAXiOeVL7DyPHqm3N
gX1EGBzwqeN9h7BeaTJvebhrvtLDU97UnPeyyFZTiSQWZhhRjqsr5mI69NvDybkq
Db1Rx/Awnqg72RtnwOPxGNlTlRMUK7PjQNW6Kc2F7iy0byyNab9BEO6DNIN8RtXS
WyioVOdFrFXIYPYnuvoPp46remUaaI4B4428cS7YfWHP5pq0j0PUj0gZnJM7aM0c
VTHkVp2eZVSBFd9/Tv1q7+2tM5PhRE8ZCKcIIqJq2UJm4+HcIXGCgpIlfW3jL4t7
qmkfu0ClnHgmoSJBycPxTPaU38FQk2ZmYcnV2RAZxtwL51q5WhAvXi0amATF2h6h
FtcAP+Iq4Xx8s+wkcaK4I/puK0+wmMyslESWhq3RfB73BKyT9/J4FONliyAQP+4M
JKkvkMAPx7Do6fqItHhbRR4FxQXg+al21UTLZ9aaY7PGjuqMZ40JY175qPG7CJFn
bEOfHQGZjLbmqJfJByG6U5mQBoLr4XzTYPrtvErV/TrTGPK4RVATXgnQ/re7TD/G
p0klPQcDHBkbnAuMVt88Q4QlqZKAov8ofLZr8IvlKsfmPFTFpfqCQCIMa1uGo6P9
v8zGHGyvZwsOXwB1vMKAfpINCR0wPTAhMAkGBSsOAwIaBQAEFJb8DGrkwS6ApBkL
0TXZXRY3WGx3BBSBXw+QkTTFm7BL+FS1KoeOupwmowICBAA=
-----END PKCS12-----
ASA9(config)#
ASA9(config)#
ASA9(config)# no crypto ca trustpoint TP
WARNING: Removing an enrolled trustpoint will destroy all
certificates received from the related Certificate Authority.
Are you sure you want to do this? [yes/no]: yes
ASA9(config)# crypto key zeroize rsa
WARNING: All RSA keys will be removed.
WARNING: All device digital certificates issued using these keys will also be removed.
Do you really want to remove these keys? [yes/no]: yes
ASA9(config)# crypto ca trustpoint TP2
ASA9(config)# crypto ca import TP2 pkcs12 123456
Enter the base 64 encoded pkcs12.
End with the word "quit" on a line by itself:
MIIGHwIBAzCCBdkGCSqGSIb3DQEHAaCCBcoEggXGMIIFwjCCBb4GCSqGSIb3DQEH
BqCCBa8wggWrAgEAMIIFpAYJKoZIhvcNAQcBMBsGCiqGSIb3DQEMAQMwDQQIp8j1
+5Rh9TQCAQGAggV4DUlYOI+VlGxuCXiGnDTYx+cR5XjPca7KW7L50D5lLQQHLr+U
fV+QVEaELnQ1MKsMm87zl9AuycuI9EeOJnPTF9Ddxy32ODzaZ4/3BaXnHl2ETyzM
IohydDJCfscT0r2TPNlE8XSknDfftK+3g3Aa0Gi+Nsq1+NXxTdYcfdXpZHvD9tk0
QZInQy1UG+NhCERyOe6SIbynuCBfksk9g+rRjeNW4bTNRDpCJ1DnrtpN6BCq8VGN
QMQagUZ1ONNLaFtQegd17RxWzXUZiWQgqf0jUZnr/BJQI9bPrISkA+JnysNU3MvS
WVKKfyGQcsYD4ExH+wi6xkohKi7hj80s9cFOyq+xpXjikZw9gKMcpoY2lLs4ivIl
4x9bB3EQ3xYW5nxbORwDx5xEyYLMUNkVRvC14ts+RB2QcEAXwq2JaaNuO6aBvjhj
8mpHjXR+wkxV8Mm+UYEed2f1SuzjtZ966OPYW0YkmXGTH+wt/rxbCROAqnmh6HGz
pU4H5/yhHgBIJOd6vZaKf5XlnX17wSniM+JRw4FsArVpuNOZFeCkDsHHFP6TPYII
h2aS2jBEH2KW0KuzEP0rHOJ8WVjZgVucSu0pb+vVGw3MzsBl14CnL5kZcPe+81wJ
XnFibhkucyo9arO/kcc7OtMcAuoktGfBVb1jrX6Se/SY8GFrzYbikNuT4DI4/dw+
OinRXOX7S/Bhaefx4JSFYoL/7agD7f+kwzv7qAEyIQtjxoGgYuqY2lZVsbZL05dJ
0D3xDkSDOc9H/5M5nZqP/xwnqVMoREPvt/a+ZdGezfzApUYUH/VAU4NzST44QcvM
mdeeizpj0VwA7WdZOrMaJll927NGb1RikmtE+6ITgdiksuJVOeNWcXuq00sDAxvZ
fv7tOQxgWX0+LNKaFd1Ef7PF9KqsJLQnbC28GC9GBNExcc9Pm+Kqfq6qj7HEosHt
kPSfLFs0kkQQzq+G4xH6pzKQkG7Yt3xjLblI9IdWsCvuHLl8fgN0LHpVXPi9iftW
PqGG8f9dCymAqHKFEnZzOiCcNlKKG+ddAN7Qb4mGVBYsaeROvVWBL2aAzIDpL7Uv
8rFHsJVKk/yCruuNSDjmbbaTlYxb2iglo2MkgGsCO5X7fOPTCO3C+UikFyOi6/7c
fSyn+LE6Za76kdRn4V2FHGG767nBxFBR/bB+uzngR+w/GzIgHQahpJ2xJlKumS2M
yiy3kGYDhIN+WV6Lz91YwZpSobk1qrcn/7fzl2FFaY6+3+AgAXiOeVL7DyPHqm3N
gX1EGBzwqeN9h7BeaTJvebhrvtLDU97UnPeyyFZTiSQWZhhRjqsr5mI69NvDybkq
Db1Rx/Awnqg72RtnwOPxGNlTlRMUK7PjQNW6Kc2F7iy0byyNab9BEO6DNIN8RtXS
WyioVOdFrFXIYPYnuvoPp46remUaaI4B4428cS7YfWHP5pq0j0PUj0gZnJM7aM0c
VTHkVp2eZVSBFd9/Tv1q7+2tM5PhRE8ZCKcIIqJq2UJm4+HcIXGCgpIlfW3jL4t7
qmkfu0ClnHgmoSJBycPxTPaU38FQk2ZmYcnV2RAZxtwL51q5WhAvXi0amATF2h6h
FtcAP+Iq4Xx8s+wkcaK4I/puK0+wmMyslESWhq3RfB73BKyT9/J4FONliyAQP+4M
JKkvkMAPx7Do6fqItHhbRR4FxQXg+al21UTLZ9aaY7PGjuqMZ40JY175qPG7CJFn
bEOfHQGZjLbmqJfJByG6U5mQBoLr4XzTYPrtvErV/TrTGPK4RVATXgnQ/re7TD/G
p0klPQcDHBkbnAuMVt88Q4QlqZKAov8ofLZr8IvlKsfmPFTFpfqCQCIMa1uGo6P9
v8zGHGyvZwsOXwB1vMKAfpINCR0wPTAhMAkGBSsOAwIaBQAEFJb8DGrkwS6ApBkL
0TXZXRY3WGx3BBSBXw+QkTTFm7BL+FS1KoeOupwmowICBAA=
quit
INFO: Import PKCS12 operation completed successfully
ASA9(config)#
ASA9(config)# sh crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 6e85f150
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Signature Algorithm: SHA1 with RSA Encryption
Issuer Name:
    hostname=ASA9+serialNumber=123456789AB
Subject Name:
    hostname=ASA9+serialNumber=123456789AB
Validity Date:
    start date: 15:52:01 UTC Jan 12 2013
    end   date: 15:52:01 UTC Jan 10 2023
Associated Trustpoints: TP2
You might want to enable debugs: "debug crypto ca 255".
Be carefull when typing password - watch out for trailing space !
Michal

Possible to select self-signed certificate for client validation when connecting to VPN with EAP-TLS

In windows 8.2, I have a VPN connection configured with PPTP as the outer protocol and EAP : "Smart card or other certificate ..." as the inner protocol. Under properties, in the "When connecting" section I've selected "Use a certificate
on this computer" and un-checked "Use simple certificate selection".
My preference would be to use separate self-signed certificates for all clients rather than having a common root certificate that signed all of the individual client certificates. I've tried creating the self-signed certificate both with and without the
client authentication EKU specified, and I've added the certificate to the trusted root certificate authority store on the client. But when I attempt to connect to the VPN I can not get the self signed certificate to appear on the "Choose a certificate"
drop down.
Are self signed certificates supported for this use in EAP-TLS? If it makes a difference, I'm working with makecert (not working with a certificate server).
TIA,
-Rick

Hi Rick,
Thank you for your patience.
According to your description, would you please let me know what command you were using to make a self-signed certificate by tool makecert? I would like to try to reproduce this issue. Also based on my experience, please let me
know if the certificate has private key associated and be present in the local machine store. Hence, please move the certificate from the trusted root certificate authority store to personal store.
Best regards,
Steven Song
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Mail App Not Working with Self-Signed Certificates

First and foremost, I apologise for starting another thread that is 90% similar to others but I wanted to avoid falling into an existing context. Like may others, I am having issues with the Mail App in Mavericks but I have an email account other than G-Mail.
That being said, here is the issue I am having. Until recently I never had an issue sending and receiving email from various accounted. My Internet provider, an Exchange account, even a G-Mail account.
Yesterday, my Web hosting provider issued a new (self-signed) certificate as the old one had expired (which was also a self-signed certificate). While I am able to still receive messages, I am no longer able to send any.
I have tried numberous possible solutions to no avail. I have removed and readded my email account, I have refreshed my SMTP settings, I have removed all semblence of the account from my Key Chain, added the Certificate manually with full trust, and I have even flushed the caches from my ~/Library/ folder. The last one perked up the Mail App but did not restore my ability to send messages from my Web provider's SMTP server.
I suspect this is a bug in the Mail App but I'm hoping I can find a few last solutions before I file a bug report.
In the meantime, I am using another outgoing server from my Internet provider. It will do but for consistency I'd much rather use the outgoing server that came with the email account in question.
I am all but convinced it is the Mail App as Thunderbird is able to use the SMTP server just fine and I am still able to send messages using the exact same settings on my iPhone and iPad.
In case it helps, I am using a Early 2011 MacBook Pro with the latest Mavericks update (which ironically was meant to solve some issues other users had with the Mail App).
On a related note, I wish I had stayed on Snow Leopard. I did not have a single issue with that OS. Now I feel like I am working on Windows Vista again and I am waiting for the Apple version of Windows 7 to set things right.

MrsCDS wrote:
I am using an iPhone 6 plus on iOS 8.1 and suddenly my Yahoo email account will not populate to my Mail app. I have deleted and re-added the account and also re-booted the phone with no luck. I get the spinning wheel up by my Wi-Fi signal that suggests it's attempting to do something, but the bottom of the Inbox only says "Updated Yesterday." Has anyone else experienced this or can someone, especially an Apple employee, tell me how to fix this?
There is no Apple in this user to user technical forum, if you want an Apple employee you would need to take your phone to the Apple store.
What happens when you switch to using cellular data? Does your email update?
FYI - Yahoo email account is notoriously bad, you can try their app.

Steps to create your own self signed certificate with java plugin working

You need two tools that comes with your jdk which are keytool and jarsigner.
Steps explain below in detail. Don't use netscape signtool, it will NEVER work!
* keytool -genkey -keyalg rsa -alias tstkey -keypass 2br2h2m -dname "cn=Test Object Signing Certificate, o=AI Khalil, ou=Java Products, c=AU"
cn = Certificate name
o = organistation
ou = organistation unit
c = country (first two letters)
If don't put the -dname, you can fill it line by line.
The -keypass has to be verify at the end, and you have to wait for it to create the rsa signing keys.
On NT by default it will put the alias information at D:\WINNT\Profiles\Administrator (if log in as administrator) with the default file called ".keystore". Windows 98 etc, don't know, search for .keystore
file. When you update it, check for the timestamp change and you know if you at the right spot.
You can store your alias information via the -storepass option to your current directory you work on, if you don't want to update the default .keystore file?
The .keystore contains a list of alias so you don't have to do this process again and again.
Another tip if you want your certificate encryption validity to be more than the default one month is simply
add the -validity <valDays>, after the -genkey option, to make your certificate usage for encryption to last much longer.
Note: You MUST use the -keyalg rsa because for starters the rsa encyption alogorthim is supported on ALL browsers instead of the default DSA and the other one SHA. Java plugins must work with the RSA algorthim when signing applets, else you will get all sorts of weird errors :)
Do not use signtool because thats a browser dependant solution!! Java plugin is supposed to work via running it owns jre instead of the browser JVM. So if you going to use netscape signtool, it starts to become a mess! ie certificate will install, but applet won't start and give you funny security exception errors :)
* keytool -export -alias tstkey -file MyTestCert.crt
It will read the alias information in the .keystore information picking up the rsa private/public keys info and
create your self sign certificate. You can double click this certificate to install it? But don't think this step is needed but maybe for IE? Someone else can check that part.
If you make a mistake with the alias, simply keytool -delete -v -alias <your alias key>
If not in default .keystore file, then simply keytool -delete -v -alias <your alias key> -keystore <your keystore filename>
* Put your classes in your jar file, my example is tst.jar.
* jarsigner tst.jar tstkey
Sign your testing jar file with your alias key that supports the RSA encryption alogorthim.
* jarsigner -verify -verbose -certs tst.jar
Check that its been verified.
The last step is the most tricky one. Its to do with having your own CA (Certified Authority) so you don't
have to fork out money straight away to buy a Verisign or Twarte certificate. The CA listing as you see in
netscape browsers under security/signers, is NOT where the plugin looks at. The plugin looks at a file called
CACERTS. Another confusion is that the cacerts file is stored in your jre/lib/security AND also at your
JavaSoft/Jre/<Java version>/lib/security. When you install the Java plugin for the first time in uses your
JavaSoft folder and its the cacerts file that has to be updated you add your own CA, because thats where
the plugin look at, NOT THE BROWSER. Everything about plugin is never to do with the browser!! :)
* keytool -import -file MyTestCert.crt -alias tstkey -keystore "D:\Program Files\JavaSoft\JRE\1.3.1\lib\security/cacerts"
Off course point to your own cacerts file destination.
Password to change it, is "changeit"
Before you do this step make a copy of it in its own directory in case you do something silly.
This example will add a CA with alias of my key called "tstkey" and store to my example destination.
* keytool -list -v -keystore "E:/jdk/jdk1.3/jre/lib/security/cacerts"
List to see if another CA is added with your alias key.
Your html, using Netscape embed and Internet explorer object tags to point to the java plugin,
your own self sign applet certificate should work
Cheers
Abraham Khalil

I follow Signed Applet in Plugin, and it's working on
my computer. Thanks
But When I open my applet from another computer on
network, why it does not work ..?
How to make this applet working at another computer
without change the policy file ..?
thanks in advance,
AnomYou must install the certificate on that computers plugin. Can this be done from the web? can anyone suggest a batch file or otherwise that could do this for end users?
I want a way for end users to accept my cert as Root or at least trust my cert so I dont have to buy one. I am not worried about my users refusing to accept my cert. just how do I make it easy for them? IE you can just click the cert from a link, but that installs for IE, and not the plugin where it needs to be.

Importing self-signed certificate

Hi there!
I have some problems in importing SSL certificates on my macbook.
There are 2 certificates that needs to be imported: the root CA certificate, which is self-signed naturally and private user certificate, which is signed by above-mentioned CA.
The first file in .crt format, which is consists of CA public key and sign. The second file in .p12 format, which is consists of encrypted public and private keys.
The problem is:
I can't import nor CA neither my personal certificate.
The CA cert should be imported at "CA" tab in keychain, but the import button ("+") is inaccesible here:
http://img.200133883.info/big//%D0%A1%D0%B2%D1%8F%D0%B7%D0%BA%D0%B0_%D0%BA%D0%BB %D1%8E%D1%87%D0%B5%D0%B9-20120313-143521.png
When I tried to double-click CA.crt I got the import error # -67762 which saying that attribute "key length" was invalid. The same thing with my personal certificate.
Could somebody explain me, how should I import those two SSL certificated?

I'm using self-signed certificate from SBS. Right now it's not the question, if something is misconfigured within my certificate (I'm aware of SBS certificate problems), the problem is that E90 WILL NOT recognize .cer or .der files as certificates.
There must be someone, who can answer this really simple question, which certificate formates are supported on E90.
You will find this type of question posted many times on different forums, with diiferent suggestion, but they simply don't work.
Again my error is "file format not supported"

Self signed certificate, key of 2048 bits, CUOM 8.7

Similar Messages

Maybe you are looking for