LSO Handling of certificates

Hi,
In my company we both have internal and external certificates associated with users who has been on either internal or external course.
The internal certificates are generated in the SAP while the external are given to the persons after ended course.
We are looking at the best way of having these certificates uploaded to the backend and tied to the P-object. Does any of you have expierence with this? What is SAP best practice on this area?
We are looking at either, Archive Link, DMS or Record Management - please advice or share your expierence
Best regards
Jakob

Hi Jakob,
We built a custom infotype to allow the administrator to define which certificate should be associated with a particular course type. Our certificates are built as SMARTFORMs, and we also provide a custom page in LSO which allows learners to view/print their certificates on their own. Certificates appear as PDF files, and we have logic to automatically populate the SMARTFORMS with the appropriate information (e.g. course title, date, instructor name (if classroom training), company logo, etc.). We also included logic in producing the certificate based on delivery method; for example, if the training was classroom based, it would include the location, but ignore this information if the delivery method is location independent (e.g. WBT or Virtual Training).
Hope this helps.
Gary

Similar Messages

ADF Mobile: Handling wildcard certificates by GeoTrust

Hello.
We have developed an application with ADF Mobile and seem to be stuck at the SSL certificate for our webservice.
We have lists of items that are filled by a java method connecting to a REST webservice. This service is secured by a wildcard certificate rather than a normal one.
Can it be that ADF Mobile's JVM can't handle the wildcard certificates? I get the error
javax.microedition.pki.certificateException: Certificate was issued by an unrecognized entity.
Our certificate was issued by GeoTrust and is valid until 2015. It shouldn't be an "unrecognized entity" then right?
Thanks for any help!
Pascal

Okay so these two things give me big trouble:
First, the JVM (J2ME Spec) doesn't include any API's to disable SSL verification as can be found here:
Re: How to Trust All SSL Certificates? (Disable Validation)
Also The RestServiceAdapter probably uses HttpConnection class which doesn't support wildcard SSL certs. The problem is known as can be read here:
http://www.sslshopper.com/article-wildcard-ssl-certificate-pros-and-cons.html
So...if the backend uses a wildcard cert and this can't be changed and the webservice has to be secured, adf mobile is no good :(

How does JRE handle PKI certificates?

I've got a bunch of Macs, all running OS X 10.10.2 and JRE 8u31 Most, no problems. But I've got two on which Java complains about the certificates of at least one web site. In the browser, the cert is just fine. Trusted, etc. Java doesn't think it's trusted. I didn't have to do anything with keystores or truststores on any of them... install java and it "just works". So I have no idea what or how Java is handling certs differently than the OS.

ANOKNUSA wrote:
Leonid.I wrote:OK, I got it. The problem is indeed related to uninstalling: /media disappeared after removal of hal <snip>
Several folk had the same problem after upgrading to KDE 4.6; no one seemed sure precisely what the culprit is. I'm gonna try and reproduce this and check for/file a bug report. You may have maimed two birds with one stone, Leonid.I
If you mean hal, then at some point, it creates a data file /media/.hal-mtab, which on old installations (that went through a lot of ext media mounts), saves the dir, even if hal is removed. Of course, a separate question is why does hal contain /media. But otherwise, Allan is right: there is no natural good way of fixing this pacman behavior.
Last edited by Leonid.I (2011-03-01 19:04:43)

How to handle Client Certificate authentication using URLRequest/URLLoader

Hi All,
I developed an AIR Application which communicates with a server. Protocol used for communication is HTTPS, and server has a valid certificate.
So whenever AIR App, communicates with the server, a dialogue box prompts to select the client certificate just as show below.
So here what I am looking at is, Any method is available to prevent this prompt.
I have already tried the method of Enabling "Dont Prompt for client certificate selection when only one certificate exists", Of course this method will work only if multiple certificate exists, so what if multiple certificate exists.
How an air application can handle that?
So any one find any way to handle this. I am using URLRequest for commnicating with server.
Here is the code snippet I have used.
var request:URLRequest = new URLRequest(url);
request.method = URLRequestMethod.GET;
var urlLoader:URLLoader = new URLLoader();
urlLoader.dataFormat = URLLoaderDataFormat.TEXT;
urlLoader.addEventListener(Event.COMPLETE, loaderCompleteHandler)
urlLoader.addEventListener(Event.OPEN, openHandler);
urlLoader.addEventListener(HTTPStatusEvent.HTTP_STATUS, httpStatusHandler);
urlLoader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
urlLoader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);//, false, 0, true);
Please help me...
Thanks
Sanal

Yes it is possible. Refer
Using Certificates for Authentication [http://docs.sun.com/app/docs/doc/820-7985/ginbp?l=en&a=view]
SSL Authentication section in [http://docs.sun.com/app/docs/doc/820-7985/gdesn?l=en&a=view]
client-auth element in server.xml [http://docs.sun.com/app/docs/doc/820-7986/gaifo?l=en&a=view]
certmap.conf [http://docs.sun.com/app/docs/doc/820-7986/abump?l=en&a=view]
certmap.conf should have verifycert "on", and lets say this certmap is called "cmverify" :
certmap cmverify default
cmverify:DNComps
cmverify:FilterComps uid
cmverify:verifycert onIn serve.xml we should have <client-auth> "required" and lets say we have an auth-db named "ldapregular":
<http-listener>...
<ssl>...
 <client-auth>required</client-auth>
</ssl>
</http-listener>
<auth-db>
<name>ldapregular</name><url>ldap://myldap:369/o%3DTestCentral</url>
<property><name>binddn</name><value>cn=Directory Manager</value></property>
<property><name>bindpw</name><value...</value><encoded/></property>
</auth-db>In ACL file we should have method = "ssl", database = "ldapregular" and certmap = "cmverify" :# clientauth against LDAP database with special certmap which has verifyCert on
acl "uri=/";
authenticate (user,group) {
 prompt = "Enterprise Server";
 method = "ssl";
 database = "ldapregular";
 certmap = "cmverify";
deny (all) user = "anyone";
allow (all) user = "alpha,beta,gamma";

2 way SSL: How does Sun implement handling malformed certificate requests?

Hi
I'd like to know how sun implements the following 2 way ssl-scenario:
When an SSL server requests client authentication, it sends a message
to the client that says "here is a list of the names of CAs that I trust
to issue client certs. If you have a client cert from one of these
CAs, then send it to me". That list is NEVER supposed to be empty.
But the hint above suggests that it is. If your server has not been
configured with the names of CAs that it trusts to issue client certs,
it's sending an empty list.
When an SSL client receives such a malformed request, with an empty
list of trusted client CA names, it may either (a) choose to send
back a response that means "I have no cert issued by any of the
issuers you have named", ***or (b) send back any certificate you have***
***and hope the misconfigured server will accept it.***
Please advice? What is the switch to tell the client to send any certificate?
Thanks a lot
Christian

That list is NEVER supposed to be empty.It doesn't actually say that anywhere in the RFC.
When an SSL client receives such a malformed request, with an empty
list of trusted client CA names, it may either (a) choose to send
back a response that means "I have no cert issued by any of the
issuers you have named", ***or (b) send back any certificate you have***
***and hope the misconfigured server will accept it.***That's not how I read the RFC. I would say the client should decide there is no suitable certificate available, and send back an empty ClientCertificate message. That in turn may provoke the server into sending a fatal handshake failure alert.
What is the switch to tell the client to send any certificate?There is no such switch.
More to the point, why is the server's CA list empty? That must mean that it has an empty truststore. That's the problem you should fix.

Clients connect to wifi with certificate that expires every month - correct way to handle expired certificates?

Hi all
I'm sorry if this is the wrong forum to ask this question. Also my knowledge in this area is somewhat limited, which I why I need your help :-)
We use wireless networks primarily in my company for all our clients and use a certificate to authenticate to the network. This certificate expires after 1 month and we automatically renew them 1 week before expiry. Relatively often we have users that
are not connected to the network for a few weeks or more and then the certificate expires before being renewed. Then we have to connect them to the wired network to get the certificate updated, so they can connect to the wireless network again.
What is the correct approach to solve this issue? We feel extending the life of the certificate would be a too big security compromise. Is there some way you could automatically allow an expired certificate briefly with the sole purpose of renewing the certificate?
Or how would you normally resolve this issue?
Thanks for any help/knowledge you can provide :-)

> Setting the validity period that high, means that the certificate could be cracked before expiry.
then you should be scary of CAs which validity is 10 or more years. And they use the same cryptography as end-entity certificates (key length and signature algorithms). It is a paranoya. Just make sure if client certificates use at least 2048 bit long
keys and use SHA1 (or better) signature algorithm. In this case there is a little chance that certificate will be successfully cracked in 2 years.
If there is an evidence (or indications) of client private key compromise -- immediately revoke the certificate and publish new CRL ASAP. You cannot protect clients from key compromise by using short-living certificates, because key compromise is ususally
achieved by gaining a control over the private key (malware on client computer). Therefore, there is nothing wrong in issuing client certificates with 1 or 2 year validity.
My weblog: en-us.sysadmins.lv
PowerShell PKI Module: pspki.codeplex.com
PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
Check out new: SSL Certificate Verifier
Check out new:
PowerShell FCIV tool.

LSO - Course Completion Certificate

Please help me with information as to where can I find a learner's Course Completion Certificate in the system or is the Certificate generated dynamically and not really stored in any table?

Matt,
SAP does deliver configuration by delivery method, but you are free to change this (add/delete/reorder infotypes as needed by delivery method). This is done via the IMG. Under Learning Solution>Basic Settings>Dialog Control-->Current Settings, you will find Maintain Personnel Actions. Here you will find the various actions for the different delivery methods, and you can review/modify as needed. Course Completion Specifications IT should be already configured for you for delivery methods like WBT and online test.
Gary

Client certificate authentication with custom authorization for J2EE roles?

We have a Java application deployed on Sun Java Web Server 7.0u2 where we would like to secure it with client certificates, and a custom mapping of subject DNs onto J2EE roles (e.g., "visitor", "registered-user", "admin"). If we our web.xml includes:
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>certificate</realm-name>
<login-config>that will enforce that only users with valid client certs can access our app, but I don't see any hook for mapping different roles. Is there one? Can anyone point to documentation, or an example?
On the other hand, if we wanted to create a custom realm, the only documentation I have found is the sample JDBCRealm, which includes extending IASPasswordLoginModule. In our case, we wouldn't want to prompt for a password, we would want to examine the client certificate, so we would want to extend some base class higher up the hierarchy. I'm not sure whether I can provide any class that implements javax.security.auth.spi.LoginModule, or whether the WebServer requires it to implement or extend something more specific. It would be ideal if there were an IASCertificateLoginModule that handled the certificate authentication, and allowed me to access the subject DN info from the certificate (e.g., thru a javax.security.auth.Subject) and cache group info to support a specialized IASRealm::getGroupNames(string user) method for authorization. In a case like that, I'm not sure whether the web.xml should be:
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>MyRealm</realm-name>
<login-config>or:
<login-config>
 <auth-method>MyRealm</auth-method>
<login-config>Anybody done anything like this before?
--Thanks

We have JDBCRealm.java and JDBCLoginModule.java in <ws-install-dir>/samples/java/webapps/security/jdbcrealm/src/samples/security/jdbcrealm. I think we need to tweak it to suite our needs :
$cat JDBCRealm.java
* JDBCRealm for supporting RDBMS authentication.
* This login module provides a sample implementation of a custom realm.
* You may use this sample as a template for creating alternate custom
* authentication realm implementations to suit your applications needs.
* In order to plug in a realm into the server you need to
* implement both a login module (see JDBCLoginModule for an example)
* which performs the authentication and a realm (as shown by this
* class) which is used to manage other realm operations.
* A custom realm should implement the following methods:
* <ul>
* <li>init(props)
* <li>getAuthType()
* <li>getGroupNames(username)
* </ul>
* IASRealm and other classes and fields referenced in the sample
* code should be treated as opaque undocumented interfaces.
final public class JDBCRealm extends IASRealm
 protected void init(Properties props)
 throws BadRealmException, NoSuchRealmException
 public java.util.Enumeration getGroupNames (String username)
 throws InvalidOperationException, NoSuchUserException
 public void setGroupNames(String username, String[] groups)
}and
$cat JDBCLoginModule.java
* JDBCRealm login module.
* This login module provides a sample implementation of a custom realm.
* You may use this sample as a template for creating alternate custom
* authentication realm implementations to suit your applications needs.
* In order to plug in a realm into the server you need to implement
* both a login module (as shown by this class) which performs the
* authentication and a realm (see JDBCRealm for an example) which is used
* to manage other realm operations.
* The PasswordLoginModule class is a JAAS LoginModule and must be
* extended by this class. PasswordLoginModule provides internal
* implementations for all the LoginModule methods (such as login(),
* commit()). This class should not override these methods.
* This class is only required to implement the authenticate() method as
* shown below. The following rules need to be followed in the implementation
* of this method:
* <ul>
* <li>Your code should obtain the user and password to authenticate from
* _username and _password fields, respectively.
* <li>The authenticate method must finish with this call:
* return commitAuthentication(_username, _password, _currentRealm,
* grpList);
* <li>The grpList parameter is a String[] which can optionally be
* populated to contain the list of groups this user belongs to
* </ul>
* The PasswordLoginModule, AuthenticationStatus and other classes and
* fields referenced in the sample code should be treated as opaque
* undocumented interfaces.
* Sample setting in server.xml for JDBCLoginModule
* <pre>
* <auth-realm name="jdbc" classname="samples.security.jdbcrealm.JDBCRealm">
* <property name="dbdrivername" value="com.pointbase.jdbc.jdbcUniversalDriver"/>
* <property name="jaas-context" value="jdbcRealm"/>
* </auth-realm>
* </pre>
public class JDBCLoginModule extends PasswordLoginModule
 protected AuthenticationStatus authenticate()
 throws LoginException
 private String[] authenticate(String username,String passwd)
 private Connection getConnection() throws SQLException
}One more article [http://developers.sun.com/appserver/reference/techart/as8_authentication/]
You can try to extend "com/iplanet/ias/security/auth/realm/certificate/CertificateRealm.java"
[http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java?r=SJSAS_9_0]
$cat CertificateRealm.java
package com.iplanet.ias.security.auth.realm.certificate;
* Realm wrapper for supporting certificate authentication.
* The certificate realm provides the security-service functionality
* needed to process a client-cert authentication. Since the SSL processing,
* and client certificate verification is done by NSS, no authentication
* is actually done by this realm. It only serves the purpose of being
* registered as the certificate handler realm and to service group
* membership requests during web container role checks.
* There is no JAAS LoginModule corresponding to the certificate
* realm. The purpose of a JAAS LoginModule is to implement the actual
* authentication processing, which for the case of this certificate
* realm is already done by the time execution gets to Java.
* The certificate realm needs the following properties in its
* configuration: None.
* The following optional attributes can also be specified:
* <ul>
* <li>assign-groups - A comma-separated list of group names which
* will be assigned to all users who present a cryptographically
* valid certificate. Since groups are otherwise not supported
* by the cert realm, this allows grouping cert users
* for convenience.
* </ul>
public class CertificateRealm extends IASRealm
 protected void init(Properties props)
 * Returns the name of all the groups that this user belongs to.
 * @param username Name of the user in this realm whose group listing
 * is needed.
 * @return Enumeration of group names (strings).
 * @exception InvalidOperationException thrown if the realm does not
 * support this operation - e.g. Certificate realm does not support
 * this operation.
 public Enumeration getGroupNames(String username)
 throws NoSuchUserException, InvalidOperationException
 * Complete authentication of certificate user.
 * As noted, the certificate realm does not do the actual
 * authentication (signature and cert chain validation) for
 * the user certificate, this is done earlier in NSS. This default
 * implementation does nothing. The call has been preserved from S1AS
 * as a placeholder for potential subclasses which may take some
 * action.
 * @param certs The array of certificates provided in the request.
 public void authenticate(X509Certificate certs[])
 throws LoginException
 // Set up SecurityContext, but that is not applicable to S1WS..
}Edited by: mv on Apr 24, 2009 7:04 AM

Safari/Mail certificate problem with gmail/google

Here is my problem:
I have set-up Mail to use my gmail account through POP. Since yesterday, when I try to get or send mail, mail gives me the error:
Unable to verify SSL server pop.gmail.com
Mail was unable to verify the identity of this server, which has a certificate issued to "pop.gmail.com'. The error was:
You might be connecting to a computer that is pretending to be "pop.gmail.com', and putting your confidential information at risk. Would you like to continue anyway?
I then have the option to show the certificate,cancel or continue. If I hit Continue, nothing happens and mail set itself to offline. If I force Mail back online (Menu Mailbox/Go Online), when it goes on the next automatic check, it turns back offline. After hours of google search, I also tried the option to show the certificate, then drag the icon of the certificate to the desktop, then open the certificate with Keychain in order to add it to the keychain but this did not work for me, keychain refused to open it and if I double-click it on the desktop it opens as a clipping content. If I change the typre/creator to force Keychain to open it, then I got an error "Unable to import an item".
I then tried to access gmail within Safari (not through POP) and I got this error when I tried to login:
Safri cannot establish a secure connection to www.google.com
At the same time, I had no problem to access it with Firefox. Back to google search, I tried to use Safari debug menu to set the security to "Performs Lax Certificate Checks" and then I could access my gmail with Safari. However the problem persists in Mail.
I believe this is a system-wide certificate issue (Firefox not affected because of a diffrent handling of certificates?not much knowledge about certificates). I tried all the standard troubleshooting:
re-boot, logoff, repair permissions, reapply latest security updates, reapply latest OS update, reset Safari, clean-up caches, discarded all mail preferences,clear-up keychain of any google/gmail.
Finally I also found in my searches to try ro download a certicate from Thawte (ThawtePremiumServerCA.cer) and add it to my keychain but this does not solve the problem.
Help will be greatly appreciated
System info: iMac G5 1.6, 1Gb RAM, OS X 10.3.9 (everything up to date according to Software update), internet connection through Airport extreme base station.

Are you saying that this is a well-recognised issue?
Can we assume that the reason for not fixing it is that Nokia want people to use Nokia Messaging instead? It came free with my phone and I did try it. It connected & synchronised well but contacts in headers kept appearing in quotes ("") and when I checked my email from my main IMAP client my sent items included incomplete versions of my emails as well as the finished email - as if it was sending drafts.
I guess I'm sticking with MfE for calendar and IMAP for email...

Unified communication certificates (UCC) : SSSLERR_SERVER_CERT_MISMATCH

Hello ,
We are using UCC (unified communication certificates) which allows us
to include multiple domains controlled in a single certificate.
http://help.godaddy.com/article/3908
We are trying to setup a secure connection from SAP ECC6 (Abap stack
7.01 SPS6) to the adress : https://serverA
When using IE, and examining the certificate installed at this adress, CN=serverB,
which contains several domains including serverA.
The ICM is in the client role
The following entry is displayed in the trace:
[Thr 1] Tue Jun 28 15:30:06 2011
[Thr 1] TRACE FILE TRUNCATED
[Thr 6] Tue Jun 28 15:30:14 2011
[Thr 6] MatchTargetName
("serverA", "CN=serverB OU=Global IT, O=****, L=****, C=FR") FA
[Thr 6] SSL NI-sock: local=160.92.204.42:53988 peer=160.92.209.8:443[Thr 6] <<- ERROR: SapSSLSessionStart(sssl_hdl=0x6000000005ce4510)
==SSSLERR_SERVER_CERT_MISMATCH
[Thr 6] *** ERROR => IcmConnInitClientSSL: SapSSLSessionStart failed (-30): SSSLERR_SERVER_CERT_MISMATCH [icxxconn_m
There is apparently a certificate mismatch issue, SAP ICM is expecting
the CN to be "serverA", instead of "serverB"
I had a look at sap note "Note 1318906 - Trace analysis of SSL
problems" which states that
"the certificate that is returned by the server is issued for a
different server name and is therefore rejected"
But by definition, when using UCC, several domains and hostnames are
secured within one CN. It means that serverA domain is
included in CN=serverB
Therefore when accessing the application with IE, there are no errors.
Is there an option on SAP ECC to be able to handle such certificates?
Thank you very much for your help.
Best Regards.

Hi Susan,
Please check the links with the same issue:
Adapter URL - hostname vs FQDN
Error using HTTPS
Internal Server Error in PI 7.1
Regards,
Naveen

Adobe 6.0 Standard - reissue of signing certificate for signing

I have a problem where an employee re-applied for their PKI (Private Key Identifier) used for signing. They were having problems with their card and needed a new one.
Now all of the old documents that were once certified and signed, Adobe says under Signature Properties: Document certification is INVALID
- The document has not been modified since it was certified
- The signer's identity is invalid because the signers Certificate has been revoked
How do I handle lost or stolen PKI cards, or employees who have left the company. We handle all certificate authentication internally. What becomes of all the old documents that no longer have valid signatures? Is there a way to recognize the old certificates as valid?

Possibly when applying for the PKI again you have the choice of
whether the old one is revoked. If, for instance, it is based on a
password that has been exposed, or a hardware card that is lost, it is
very important that ALL documents be revoked, because there is no way
to tell the difference between those validly signed, and those later
fraudulently signed.
Hopefully someone else will have more specific advice for this case.
Aandi Inston

Https, secure browsing, certificates

In Safari on the iTouch (2.1 software, and presumably the same as iPhone) I can connect to an https site. I can see the little lock icon in the address bar. But how do I know that the certificate has actually been checked and verified?
In Safari on the Mac, if I click the equivalent lock icon, I can see the certificate. This doesn't work AFAICT on the touch, the lock icon seems to only be a display. I've been trained to check the certificate before trusting the website with passwords tied to money etc.
I could believe that in this stripped-down version of Safari, they don't have the hooks to view the certificate, and maybe I will just get a warning if it can't be verified, or maybe there won't be a lock icon? But I haven't been able to find that documented anywhere. For all I know, this stripped-down Safari doesn't check certificates at all.
Can anyone shed any light on this, and if you think you know, point me at some Apple documentation that makes this clear?
I'd really like to use my touch to access eBay, etc., but not if I can't be sure I'm really on a secure page.

DaVBMan wrote:
Try this search out and see if you can find what you are looking for.
http://www.google.com/search?source=ig&hl=en&rlz=&q=certificatesiphone+safarisite%3Asupport.apple.com%2Fkb
Thanks, actually it does. Most of this is either Mac/Safari or Enterprise client-side certs I'd previously mentioned, but the first link,
http://support.apple.com/kb/HT2351
"About the security content of iPhone v2.0 and iPod touch v2.0"
probably puts the question to rest.
+CVE-ID: CVE-2008-1589+
+Description: When Safari accesses a website that uses a self-signed or invalid certificate, it prompts the user to accept or reject the certificate. If the user presses the menu button while at the prompt, then on the next visit to the site, the certificate is accepted with no prompt. This may lead to the disclosure of sensitive information. This update addresses the issue through improved handling of certificates. ...+
I think this statement of expected behavior, plus some of the information provided in the other thread I mentioned, pretty much makes clear that it works as expected to check certificates. I'm confident enough that I won't hesitate to access secure sites with my CC while traveling.
I still maintain there's room for improvement in both the operation (display certificates) and documentation of Mobile Safari wrt https (a patch notification summary for now-obsolete versions of firmware is not how this important info should get communicated to users, IMO). But I won't beat this dead horse any further. My question is answered to my satisfaction.
Thanks again to all.

How to create a Certificate that gets validated by Mozilla

Hi,
I've written an application that enables it's user to act as a CA.
He can create Key-Paris, Certificates, sign Certificates and various other things.
Among them he is able to export any KeyStore-Entry (i.E. a Key-Pair) to a PKCS#12 file.
The problem that I am encountering here is, that Mozilla Browsers (i.E. Firefox) won't recognize the importet Certificate as a valid one. It says "The certificate couldn't be verified for unknown reason" (sorry, but I can't provide the exact error message because I use a localized build of firefox).
What I do in order to reproduce this Problem is basicly this:
- Create a Key-Pair
- Create a (self-signed) certificate from the Public-Key
- Store them as a PrivateKeyEntry in my KeyStore
- sign the certificate with my self-signed CA-Certificate
- export my CA-Certificate to Firefox
- export my PrivateKeyPair to a PKCS#12-File wich I import with Firefox
Any help would be greatly apreciated.

(I would have appreciated it if you had pasted the certificate with the line-breaks, as required for PEM format certificates. Nevertheless...)
Your certificate shows why Mozilla will not recognize the self-signed certificate from keytool as a Root CA: it does not contain the SubjectKeyIdentifier or AuthorityKeyIdentifier extensions in them.
RFC3280 (http://www.ietf.org/rfc/rfc3280.txt) states the following:
Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
4.2.1.3), and certificate policies (section 4.2.1.5) extensions.Implementors of software that handle digital certificates choose to implement PKIX standards in stages; Mozilla has implemented more PKIX standards than keytool does, so while keytool will recoginize a Mozilla (or other PKIX-compliant) CA certficate, almost no PKIX-conformant certificate-handling software will handle self-signed CA certs issued by keytool.
I would recommend you download something like EJBCA or OpenCA from sourceforge.net to create your self-signed CA. Ultimately, your CA certificate must look something like this (don't miss the SubjectKeyIdentifier and AuthorityKeyIdentifier extensions):
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            2b:d0:5f:b0:71:64:67:0e
        Signature Algorithm: 1.2.840.113549.1.1.11
        Issuer: CN=StrongKey DEMO Root CA, OU=For StrongKey DEMO Use Only, O=StrongAuth Inc
        Validity
            Not Before: Jul 25 16:02:17 2006 GMT
            Not After : Jul 22 16:12:17 2016 GMT
        Subject: CN=StrongKey DEMO Root CA, OU=For StrongKey DEMO Use Only, O=StrongAuth Inc
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (4096 bit)
                Modulus (4096 bit):
                    00:88:42:9c:c0:40:1f:06:8a:f7:55:93:c5:35:4b:
                    54:38:58:61:9b:04:2b:61:07:44:05:76:42:f9:e8:
                    2d:b9:99:c5:84:16:b1:40:43:5b:06:ca:fc:9b:d4:
                    59:f7:d6:2e:28:78:63:12:09:58:9e:db:a2:91:c2:
                    58:b5:5b:1e:9f:5e:cd:57:bb:83:ec:10:85:45:c3:
                    ee:0e:f7:6a:71:63:95:5f:5c:ce:6c:fd:43:54:bd:
                    af:ef:63:ae:e3:37:18:44:7b:2c:a3:7f:8d:00:04:
                    9a:a4:7e:48:c9:9e:c6:de:65:40:17:f6:3e:58:3b:
                    b1:f2:a9:4b:61:fb:d7:52:b2:c7:7f:22:25:5b:53:
                    c3:0e:22:94:17:21:ce:82:c3:79:cd:96:9f:cd:7e:
                    b2:b5:f4:0a:38:ac:1a:2d:bb:21:66:b5:20:43:3d:
                    94:85:fa:2b:a7:53:88:43:bc:9b:03:d2:5e:4a:dc:
                    d0:90:ac:55:99:54:5c:34:d2:f0:8e:18:ff:ea:12:
                    14:da:7f:77:63:30:d1:75:77:f1:ef:ac:11:3a:48:
                    43:c3:d0:f9:bb:1e:07:f5:6e:da:c9:ab:88:ff:e2:
                    ad:b8:24:e6:b1:3a:88:14:69:0b:41:3e:b0:02:00:
                    61:b3:a0:43:b2:46:3a:b8:37:a8:c3:57:a6:db:71:
                    78:97:04:cf:19:e8:e8:5a:c9:1a:73:77:75:36:5e:
                    19:7b:f6:24:fa:2d:df:19:5c:5c:3d:a3:79:aa:81:
                    55:5b:34:4a:c5:7d:85:e5:d9:ee:5f:74:30:5f:23:
                    63:e9:45:49:5d:d6:ef:95:32:d3:2c:10:08:86:06:
                    be:79:3c:3c:f8:82:b7:37:2c:dd:59:66:96:fe:cf:
                    9a:60:58:23:a1:26:ff:16:f0:c9:55:bf:27:fc:af:
                    de:6a:11:da:9a:c8:65:77:e4:ca:b6:2f:d3:58:ef:
                    93:1b:34:de:3a:81:07:b7:12:b2:61:83:a2:77:fc:
                    f3:53:fc:c2:71:db:d2:97:c5:50:c8:34:e8:4e:54:
                    da:c3:fb:31:79:34:c2:eb:b3:e0:be:38:fc:1e:5c:
                    ca:04:13:83:9e:e3:b0:66:30:33:56:82:d6:dd:c9:
                    94:9d:3b:ca:10:f6:fc:99:05:e2:de:ca:0c:d6:6b:
                    60:a6:f8:29:fc:c4:18:82:ae:38:c2:9f:62:fe:3a:
                    66:da:8c:17:12:a1:24:4c:a3:a6:9b:7b:bb:54:b8:
                    da:ff:e2:81:a7:33:54:0b:17:ee:2a:db:d4:e3:1d:
                    42:23:c1:8b:01:9e:42:8f:da:62:7b:21:9a:1c:b6:
                    9c:f3:28:75:16:11:23:d0:42:65:cc:34:70:9e:f1:
                    04:00:77
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
            CA:TRUE
            X509v3 Key Usage: critical
            Digital Signature, Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier:
            82:05:B5:4B:E2:61:B0:C9:7A:6F:0F:D1:CC:A0:C3:62:FB:D2:5A:02
            X509v3 Authority Key Identifier:
            keyid:82:05:B5:4B:E2:61:B0:C9:7A:6F:0F:D1:CC:A0:C3:62:FB:D2:5A:02
            X509v3 Certificate Policies:
            Policy: 1.3.6.4.1.10514.509.1.4
    Signature Algorithm: 1.2.840.113549.1.1.11
        63:94:13:a9:6a:3b:a8:aa:34:e6:2b:0f:20:a9:55:d8:80:e8:
        54:0f:6a:15:b0:76:91:0d:98:a4:75:f9:50:09:2e:cf:30:2e:
        15:bc:21:c2:fe:f0:36:4b:60:7d:bb:b8:76:bd:9d:2b:d8:a5:
        a6:e7:60:83:00:f3:9c:65:f1:f7:b8:16:f7:72:ab:70:d7:c4:
        60:bf:fb:33:1e:67:e6:fa:a1:d0:23:5f:bf:69:fc:25:19:71:
        5a:c1:41:a3:ab:9b:da:09:92:2c:ee:83:c2:de:61:3a:b2:a4:
        c6:18:6d:dd:ef:77:2b:91:40:c5:9c:fb:61:66:f5:2d:4f:20:
        5a:c5:b6:1b:08:4b:a4:18:a7:b4:86:07:e1:c8:c1:a7:e3:8f:
        cf:01:4b:a4:a6:07:b3:65:5f:0a:1d:a1:7d:52:12:c3:43:8b:
        72:16:75:78:0a:b0:39:8a:92:33:4b:0e:ef:a8:c1:33:2e:cc:
        96:fd:a1:b1:2e:0b:1c:68:ff:fa:48:4f:43:60:32:a0:4f:9a:
        c0:29:e3:66:b9:ce:cb:0b:99:67:c0:74:33:4f:9b:e3:db:68:
        b9:ea:c2:67:f0:7a:db:88:93:7b:cf:5f:da:3b:ea:61:88:24:
        e7:82:5e:ce:be:39:c3:de:03:b5:42:3b:b3:50:12:95:25:b9:
        dc:7a:66:95:3b:97:6a:85:06:66:68:84:0f:3d:5b:93:de:2e:
        44:2e:58:97:1b:8b:56:db:7a:27:58:fe:ad:3c:32:4e:09:f9:
        60:2e:c0:3b:b4:80:53:04:41:ae:53:ff:b2:b7:f0:4d:72:9f:
        8b:59:14:7f:cc:42:83:74:3a:08:1c:2a:ab:95:7e:8e:ee:51:
        eb:2a:4c:82:5c:12:17:ec:22:92:93:22:62:55:36:91:6a:d7:
        5b:55:2d:46:e7:d4:30:fd:d5:c4:87:be:ea:a9:2c:fe:ac:5b:
        d7:51:fc:c7:4d:72:6a:f5:3e:40:ef:f7:63:8f:94:8c:95:f4:
        0f:4d:b0:02:31:9a:86:5f:0c:ce:f0:de:18:92:a8:09:3b:f9:
        3f:9b:95:5c:0e:ab:82:22:41:cc:7f:e2:83:d7:2f:cf:bc:1b:
        d7:65:ce:c1:7f:42:8d:5e:36:00:d6:14:42:0b:52:9b:23:46:
        5c:83:bb:ce:b8:e1:ac:43:b5:fb:c9:00:f7:cf:8d:2f:98:b8:
        99:f0:fb:a8:3b:38:df:a5:19:c6:d7:a8:f8:aa:9a:4d:50:4f:
        0a:f7:19:82:16:e0:92:6b:fc:47:a9:b3:c0:09:a4:ac:7b:8f:
        15:aa:60:c6:f3:4f:fa:1d:17:5c:24:bc:5b:3b:3e:8b:28:48:
        3d:26:c5:31:7e:f3:cb:36
-----BEGIN CERTIFICATE-----
MIIFvjCCA6agAwIBAgIIK9BfsHFkZw4wDQYJKoZIhvcNAQELBQAwYDEfMB0GA1UE
AxMWU3Ryb25nS2V5IERFTU8gUm9vdCBDQTEkMCIGA1UECxMbRm9yIFN0cm9uZ0tl
eSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIEluYzAeFw0wNjA3
MjUxNjAyMTdaFw0xNjA3MjIxNjEyMTdaMGAxHzAdBgNVBAMTFlN0cm9uZ0tleSBE
RU1PIFJvb3QgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2UgT25s
eTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQCIQpzAQB8GivdVk8U1S1Q4WGGbBCthB0QFdkL56C25mcWEFrFA
Q1sGyvyb1Fn31i4oeGMSCVie26KRwli1Wx6fXs1Xu4PsEIVFw+4O92pxY5VfXM5s
/UNUva/vY67jNxhEeyyjf40ABJqkfkjJnsbeZUAX9j5YO7HyqUth+9dSssd/IiVb
U8MOIpQXIc6Cw3nNlp/NfrK19Ao4rBotuyFmtSBDPZSF+iunU4hDvJsD0l5K3NCQ
rFWZVFw00vCOGP/qEhTaf3djMNF1d/HvrBE6SEPD0Pm7Hgf1btrJq4j/4q24JOax
OogUaQtBPrACAGGzoEOyRjq4N6jDV6bbcXiXBM8Z6OhayRpzd3U2Xhl79iT6Ld8Z
XFw9o3mqgVVbNErFfYXl2e5fdDBfI2PpRUld1u+VMtMsEAiGBr55PDz4grc3LN1Z
Zpb+z5pgWCOhJv8W8MlVvyf8r95qEdqayGV35Mq2L9NY75MbNN46gQe3ErJhg6J3
/PNT/MJx29KXxVDINOhOVNrD+zF5NMLrs+C+OPweXMoEE4Oe47BmMDNWgtbdyZSd
O8oQ9vyZBeLeygzWa2Cm+Cn8xBiCrjjCn2L+OmbajBcSoSRMo6abe7tUuNr/4oGn
M1QLF+4q29TjHUIjwYsBnkKP2mJ7IZoctpzzKHUWESPQQmXMNHCe8QQAdwIDAQAB
o3wwejAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQU
ggW1S+JhsMl6bw/RzKDDYvvSWgIwHwYDVR0jBBgwFoAUggW1S+JhsMl6bw/RzKDD
YvvSWgIwFwYDVR0gBBAwDjAMBgorBgQB0hKDfQEEMA0GCSqGSIb3DQEBCwUAA4IC
AQBjlBOpajuoqjTmKw8gqVXYgOhUD2oVsHaRDZikdflQCS7PMC4VvCHC/vA2S2B9
u7h2vZ0r2KWm52CDAPOcZfH3uBb3cqtw18Rgv/szHmfm+qHQI1+/afwlGXFawUGj
q5vaCZIs7oPC3mE6sqTGGG3d73crkUDFnPthZvUtTyBaxbYbCEukGKe0hgfhyMGn
44/PAUukpgezZV8KHaF9UhLDQ4tyFnV4CrA5ipIzSw7vqMEzLsyW/aGxLgscaP/6
SE9DYDKgT5rAKeNmuc7LC5lnwHQzT5vj22i56sJn8HrbiJN7z1/aO+phiCTngl7O
vjnD3gO1QjuzUBKVJbncemaVO5dqhQZmaIQPPVuT3i5ELliXG4tW23onWP6tPDJO
CflgLsA7tIBTBEGuU/+yt/BNcp+LWRR/zEKDdDoIHCqrlX6O7lHrKkyCXBIX7CKS
kyJiVTaRatdbVS1G59Qw/dXEh77qqSz+rFvXUfzHTXJq9T5A7/djj5SMlfQPTbAC
MZqGXwzO8N4YkqgJO/k/m5VcDquCIkHMf+KD1y/PvBvXZc7Bf0KNXjYA1hRCC1Kb
I0Zcg7vOuOGsQ7X7yQD3z40vmLiZ8PuoOzjfpRnG16j4qppNUE8K9xmCFuCSa/xH
qbPACaSse48VqmDG80/6HRdcJLxbOz6LKEg9JsUxfvPLNg==
-----END CERTIFICATE-----BTW, why are you using a non-standard key-size of 1023 bits?

EAP in ayncronos interface (Authetitication with certificates)

We want to know if it is posible to login for asyncronous interfaces with certificates

It depends on what you are doing on the async interface. If there is a "dumb" terminal connected to it you will not be succesfull. The end host must have enough intelligence to handle the certificate. It will be possible if you are running ip over the link. (example: SLIP or ISP dial-up)
However: Authenticating and negotiating the certificate involves quite some traffic and hence I would not recommend using this option while many async lines will simply not offer sufficient reliability and bandwidth.
Regards,
Leo

EAP personal certificate 5800

Hi i have been trying to use the wireless at my college with my nokia 5800 but it seems that the certificates that the college provides are not working with my phone. I have been able to load the .cer file into the authority certificate but im failing with the personal certificate (.pem extension). Whenever i try to save it to my phone it only attaches it to the notes and according to the IT department the personale certificates are required to use the 802.x that the college provides.
Any ideas how can i get the .pem file to work in the phone?
Thanks for the help!

fmartell wrote:
Hi i have been trying to use the wireless at my college with my nokia 5800 but it seems that the certificates that the college provides are not working with my phone. I have been able to load the .cer file into the authority certificate but im failing with the personal certificate (.pem extension). Whenever i try to save it to my phone it only attaches it to the notes and according to the IT department the personale certificates are required to use the 802.x that the college provides.
Any ideas how can i get the .pem file to work in the phone?
Thanks for the help!
You would need to convert your personal certificate from it's current PEM format to PKCS#12 (.pfx) format. PKCS#12 format should be installable on the phone assuming that content and capabilities of the certificate and the private key itself are compatible with the phone. PKCS#12 file will be single password protected .pfx file (a container) including both the private key and personal certificate. Sometimes PKCS#12 .pfx file may also include the CA certificate(s) so that CA certificate don't need to be installed separately from the personal certificate.
Conversions between different certificate file formats can be done with OpenSSL. OpenSSL is a open source command line tool for handling various certificate related operations. It is rather complex and powerful set of tools but e.g. a conversion between PEM and PKCS#12 format is typically not too difficult to do once you have a PC with OpenSSL available. Of course using command line based tools like OpenSSL will require certain amount geekiness but nothing too extreme.
If you feel comfortable to give OpenSSL conversion a try you can find OpenSSL installation package for Windows e.g. by googling "Win32 OpenSSL" and installing it on a Windows PC. I think that the "light" Win32 version of the OpenSSL installation packages provided by the Shining Light Productions web page should be sufficient enough for a simple conversion task like this. Once you have the OpenSSL installed and functional on a PC you can proceed to the actual conversion. In case you have access to a Linux PC it might already have the OpenSSL installed if your locky. Point is that you don't necessarily need to have a Windows version of the OpenSSL to do this conversion but basically any PC with OpenSSL should be good for the task.
First you should propably take a look at your PEM file with text editor (e.g. open with Wordpad on a Windows PC) and see if the PEM file contains both "BEGIN / END PRIVATE KEY" and "BEGIN / END CERTIFICATE" tags with some code between the BEGIN and END tags since this indicates that both private key and the actual certificate are included in this single PEM file you have received.
If your PEM file does not contain the "PRIVATE KEY" section then you should also have received a separate private key file (named .key .pvk .pem or something else) in addition to the "certificate only" PEM file from the people who provided the certificate.
Copy your PEM formatted certificate file(s) to your PC with the OpenSSL, start the command line and go to the folder where your certificate files are located. Assuming that your PEM file includes both the certificate and the private key then these can be converted to PKCS#12 format using following OpenSSL command:
openssl pcks12 -export -in yourcertificate.pem -out yournewcertificate.pfx
After entering this command OpenSSL will prompt you to provide a password that will be used for protecting the new PKCS#12 (.pfx) file. Select and enter a password (twice) and note that you will need to remember this later when installing the resulting .pfx file on your phone.
In case you have a separate private key file in addition to personal certificate PEM file then format of the OpenSSL command that creates a single PKCS#12 pfx file (containing both private key and personal certificate) would be something like this:
openssl pkcs12 -export -in yourcertificate.pem -inkey yourprivatekey.pvk -out yournewcertificate.pfx
Naturally you need to replace the filenames in above example following the "-in" and "-inkey" options with the actual names of your files and you should define a filename for the resulting .pfx file after the "-out" option (ensure that you won't end up overwriting the existing PEM file and keep a copy of it in some other folder in any case).
It's important to note that you must have both the personal certificate and it's private key installed on the phone in order to be able to use your personal certificate for EAP-TLS authentication (these are both most likely included in your PEM file). Naturally you will also need to have the Certificate Authority certificate installed on the phone but it sounds that you had already managed to install that one. The PEM file (like PFX file) might also contain the both the CA certificate and personal certificate so don't worry if you get "certificate already installed" type of warning when installing the PKCS#12 (.pfx) file on the phone later since it means that your original PEM file also contained the CA certificate which got automatically included to .pfx file during the conversion and since you had already previosly installed the same CA certificate phone just notes that this CA is already installed.
Once you have successfully converted your personal certificate and private key in to the PKCS#12 (.pfx) file format then you should be able to copy the resulting .pfx file (created by OpenSSL) to your phone and hopefully install it on the phone.
Note that your phone will ask you to define a "phone key store" password (select a password you wish and enter it twice) when you are installing first "personal certificate" on your phone. Once you have created the phone key store password you will be prompted for the password of the PKCS#12 (.pfx) file so this is the password that you entered during the OpenSSL conversion.
Ensure that you will also remember your newly created private key store password since it will be prompted by the phone later when this particular personal certificate is being used for the EAP-TLS authentication.
If you managed to install your personal certificate (and the private properly) then you should be able to go to your access point's EAP-TLS settings and select your certificateas a personal certificate and select the previously installed CA certificate as a Certificate Authority for the EAP-TLS authentication.

LSO Handling of certificates

Similar Messages

Maybe you are looking for