Digital Transformation . API . Integration . IAM

In today's digital world, security is paramount, especially when it comes to the transfer of sensitive information over the internet. One of the foundational elements of securing online communications is the use of SSL (Secure Sockets Layer) certificates. SSL certificates are critical for establishing a secure connection between a web server and a client, ensuring that the data transmitted remains private and integral. This article delves into the importance of SSL certificates, the various formats they come in, and provides practical guidance on handling the PFX format, including how to convert it to other commonly used formats. The Question: Why SSL Certificates are Important? The SSL certificates provides the transport layer security and hence it's important in modern web apps accessible over http/ https protocol. Following are some of the key advantages of SSL certificates - Data Encryption -  SSL certificates encrypt the data exchanged between the client and the server. Th

Kubernetes common errors 1. **CrashLoopBackOff**: - **Description**: A pod repeatedly crashes and restarts. - **Troubleshooting**: - Check pod logs: `kubectl logs <pod-name>`. - Describe the pod for more details: `kubectl describe pod <pod-name>`. - Investigate the application's start-up and initialization code. 2. **ImagePullBackOff**: - **Description**: Kubernetes cannot pull the container image from the registry. - **Troubleshooting**: - Verify the image name and tag. - Check the image registry credentials. - Ensure the image exists in the specified registry. 3. **Pending Pods**: - **Description**: Pods remain in the "Pending" state and are not scheduled. - Troubleshooting: - Check node resources (CPU, memory) to ensure there is enough capacity. - Ensure the nodes are labeled correctly if using node selectors or affinities. - Verify there are no taints on nodes that would prevent scheduling. 4. Node Not Ready: - Description: One or more node

Hi All, Let me share an interesting topic of WSO2 API Manager. The scenario has been tested with WSO2 API Manager v4 series as on date. So, below is the use case and analysis of the same. Use Case- There came a scenario where we need to expose an API endpoint with no security i.e. API Gateway is just acting as a medium to route the traffic to the backend service while no security to be applied. So, the API would be accessible without access token or apikey. To achieve this, I have disabled the security header via publisher for respective resource and published the same with new revision in API Manager 4 (apim 4.1.0 in my case). The API is having 1 resource with GET method; so directly calling the API URL in the browser was giving the response as expected. Also the Subscription quota was at API level with Unlimited Tier Below screenshot shows how to disable the security for respective resource- Figure- Disable Security of API Resource in WSO2 APIM via Publisher Portal Problem Statement

Hi Everyone, in this blog I am going to share about in-memory deployment process of APIs in WSO2 API Manager 4. Deployment Process for APIs- Whenever an API is deployed via publisher portal, it generates the API Synapse artefacts and stores the same. In previous versions of WSO2 API Manager (till apim v3.2.x), the API artefacts were stored in database as well as in the file system at following location- AM_HOME/repository/deployment/server/synapse-configs/default/api/ <PROVIDER-API-Version.xml> Changes in API Manager 4-  Starting with WSO2 APIM v4, WSO2 has changed the deployment and loading process of the APIs as- API-Related Synapse artefacts were moved from the file system to the In-Memory During the server startup and revision deployment, artefacts will be loaded from DB to memory So, after this important change in WSO2 API Manager 4, the API artefacts are loaded from following database tables to In-Memory- AM_GW_PUBLISHED_API_DETAILS  ; AM_GW_API_ARTIFACTS; AM_GW_API_DEPLOY

Recently we have come across a requirement where the endpoint URL security has been upgraded from TLSv1.2 to TLSv1.3 and our API integration got broken with WSO2 APIM v3.2. Below is the summary of the incident and how I overcome this situation with support. Environment - WSO2 API Manager v3.2.0.221, RHEL 8.3, OpenJDK1.8.291 Problem Statement - API based integration got broken due to endpoint URL TLS upgrade to TLSv1.3. while WSO2 API Manager has a support with TLS1.2 only. We got the error as mentioned below- ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O error: Received fatal alert: protocol_version javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version at sun.security.ssl.Alert.createSSLException(Alert.java:131) at sun.security.ssl.Alert.createSSLException(Alert.java:117) at sun.security.ssl.TransportContext.fatal(TransportContext.java:311) at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)